Revisiting some Og issues again: RFC

Ruby Apps Nitro
1

Hi Devs,
Reviewing some posts over the last few months, I’ve made a summary (in
no particular order) and proposal.
I’ve not quoted names since this i just my impression.

Observations:

  • There is widespread interest in Og as a standalone project.
  • Og is incorrectly considered as being bound to Nitro.
  • Specs and developer level documentation are scarce.
  • Intermediate level documentation of Og is scarce, i.e. for people
    wanting to write user level docs.
  • Confusion exists about what version of Og is ‘current’.
  • Confusion exists about what the Og roadmap is.
  • Darcs may be a barrier to entry (cf svn, git, mercurial…?).
  • Og needs a stable branch and a development branch.

It seems there was some interest in volunteering to help on different
aspects, of the above, but this might have changed over the last few
months.

Is it worth considering setting up something like Og-dev on google
code or some such service, calling that the development branch and
inviting committers, Rubinius style?
This would allow people to tackle any of the above issues they wished
to.
Given this would be aimed at the intermediate/developer level much of
the results of this effort would feed into a stable branch as things
are ironed out?

Mark

2

Hi all

I hope you are having fun with your things and lives.

I believe it makes a lot of sense to de-couple Og like this. I’m all
for
it.

w.

3

Mark Van De Vyver schreef:

wanting to write user level docs.
code or some such service, calling that the development branch and
http://rubyforge.org/mailman/listinfo/nitro-general

Hi Mark, devs,

I was under the impression that a seperate repo for Og was in the
making, any news from the trenches? Trans? George?

This project does have a history of not giving anyone direct commit
access. I’m not sure if this is more a technical/security issue with the
current hosting of the repo, or rather a very deliberal policy.

Since there’s not much reaction, positive or negative, I would suggest
you just go ahead and do it. Set up a development/experimental Og branch
somewhere that is more accessible to developers. My impression is that
any ‘should we do this’ type of questions don’t get much feedback here,
but any tangible contribution is appreciated. If you can get more
developers involved it can only improve the project in the end.

FWIW,
(ab)

–
Arne B.
http://www.arnebrasseur.net
http://www.zhongwiki.com
http://www.bankske.org
[email protected]

4

I was under the impression that a seperate repo for Og was in the
making, any news from the trenches? Trans? George?

Tom is doing some Nitro related work at the moment. When he is finished
with
this, perhaps he can work on creating a separate repo for Og.
I have no time to do this myself, but I will gladly help Tom.

-g.

5

On Nov 28, 2007 3:50 PM, Arne B. [email protected] wrote:

  • Specs and developer level documentation are scarce.

Nitro-general mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/nitro-general

Hi Mark, devs,

I was under the impression that a seperate repo for Og was in the
making, any news from the trenches? Trans? George?

Yep, that’ll probably still happen, but a separate repo doesn’t
address many of the issues people have raised.

This project does have a history of not giving anyone direct commit
access. I’m not sure if this is more a technical/security issue with the
current hosting of the repo, or rather a very deliberal policy.

It’s a very good policy when:

  • there are no specs to test aginst
  • the code is used in a production environment

So I’m not complaining, or suggesting a change as long as those two
characteristics remain.

Since there’s not much reaction, positive or negative, I would suggest
you just go ahead and do it. Set up a development/experimental Og branch
somewhere that is more accessible to developers. My impression is that
any ‘should we do this’ type of questions don’t get much feedback here,
but any tangible contribution is appreciated. If you can get more
developers involved it can only improve the project in the end.

I’m leary of anything that might fragment efforts - dev time is a
scarce/finite resource.
I’m in a position to contribute occasionally but not experienced
enough to lead something like this.
I’m happy to wait and see what interest there is.

Thanks
Mark

6

On Nov 28, 3:22 am, “George M.”
[email protected] wrote:

I was under the impression that a seperate repo for Og was in the
making, any news from the trenches? Trans? George?

Tom is doing some Nitro related work at the moment. When he is finished with
this, perhaps he can work on creating a separate repo for Og.
I have no time to do this myself, but I will gladly help Tom.

This is what I’m thinking for that.

One of the nice things about SVN is that is can house sub-projects,
ie. and you can check out any part of a repo separately from the rest.
This is unlike Darcs which requires us to check out the whole she-bang
–which is exactly why we don’t a separate development track for Og.

So I’d like to setup an SVN repo on Rubyforge under the the nitro
project. However, we don’t want to loose distributive scm either –
that’s why we all love darcs. Well, we can retain dscm if we use git
and svn-git. I love darcs, but the tide is with SVN and the future
looks to be going to git*. I see git as the progeny of darcs, so to me
using git instead of darcs is (mostly) just taking a step sideways.

So the idea then is that we have a central svn repo and we us git, via
svn-git, to work with it. I realize it’s off the beaten track, but I
think in the end it’s probably the best all around solution.

T.

  • albeit mercurial (hg) is giving it a run for the money --however it
    lacks bidrectional svn sync.
7

Oh, and a helpful link I discovered today related to this:

http://blog.new-bamboo.co.uk/2007/8/16/using-git-for-rails-development

T.

8

On Nov 28, 8:37 pm, “Judson L.” [email protected] wrote:

I tentatively agree that it would be preferable not to create a complete
fork of Og as it stands, with regards to limited developer resources. But I
wonder if there might be more potential devs for a standalone Og than there
are for Og-in-Nitro.

I understand you’re take here. It’s different with SVN in that one
repository can house many separate projects. For instance my ProUtils
repo has a number of projects and the layout of the repo clearly
demonstrates the fact:

proutils/svn/
box/
branches
tags
trunk
icli/
branches
tags
trunk
mint/
branches
tags
trunk
…

This is what I’d like to do with Nitro’s repo and start thinking of
Nitro as an umbrella repo which contains a number of separate projects
instead of a project in itself. But this would mean that Raw would
become more of what Nitro is considered today. Maybe that’s not
reasonable, but I was hoping to keep the all the Nitro projects under
one “roof” while having independent dev tracks at the same time.

The downside of a pure Git repo is that it would have to be hosted by
a private system (no public “forges” I know of support git) and also
anyone on Windows would not have access to the repo (maybe not that
big a deal, but something to be considered nonetheless).

T.

9

I realize I’ve been out of the loop for no little while now, but this
exchange struck a chord with me, especially as I’m turning my interest
back
to Og. Mark’s summation could very well be a statement of purpose for
me
regard Og.

  • There is widespread interest in Og as a standalone project.
  • Og is incorrectly considered as being bound to Nitro.
  • Specs and developer level documentation are scarce.
  • Intermediate level documentation of Og is scarce, i.e. for people
    wanting to write user level docs.
  • Confusion exists about what version of Og is ‘current’.
  • Confusion exists about what the Og roadmap is.
  • Darcs may be a barrier to entry (cf svn, git, mercurial…?).
  • Og needs a stable branch and a development branch.

I very much want to see Og as a separate project. I think it’s a very
useful library, with a excellent philosophic basis. I remain eager to
commit to it’s development, specs and doc. On the other hand, I
candidly
have little interest in Nitro, and Og’s coupling with Nitro both
frustrates
and distances me. I do thank the Nitro project for engendering in me a
keen
dislike for Darcs though.

I realize that I’ve contributed only a little to Og, and it was a long
time
ago, but I’m a little in love with it as a library, and I feel strongly
about it.

So the idea then is that we have a central svn repo and we us git, via

svn-git, to work with it. I realize it’s off the beaten track, but I
think in the end it’s probably the best all around solution.

All that in mind, my thought is this: what does a hybrid svn/git SCM
solution get us? Is it that difficult to set up a head git repo? I’d
argue
against using the Rubyforge Nitro SVN specifically because I’d prefer to
see
Og take off as a separate project.

I tentatively agree that it would be preferable not to create a complete
fork of Og as it stands, with regards to limited developer resources.
But I
wonder if there might be more potential devs for a standalone Og than
there
are for Og-in-Nitro.

(I’d argue for monotone, but I’m more than willing to take git for a
spin.)

Judson

10

On Nov 28, 2007 8:22 PM, Trans [email protected] wrote:

This is what I’d like to do with Nitro’s repo and start thinking of
Nitro as an umbrella repo which contains a number of separate projects
instead of a project in itself.

I understand the “one roof” idea, but I don’t see it’s appeal. Why do
you
want to see an “umbrella” project? Does Facets belong inside the Nitro
tent? If not, then why does Og? It seems like both Nitro and Og
might be
better served if they were separated, with Nitro being a sort of
first-client for Og, in terms of testing, features, etc.

…and also

anyone on Windows would not have access to the repo (maybe not that
big a deal, but something to be considered nonetheless).

Huh. I’d been looking for the comparisons between Monotone and Git, and
that one is kind of huge if you aren’t developing for the Linux kernel.

11

Hi Devs,

On Nov 29, 2007 3:22 PM, Trans [email protected] wrote:

solution get us? Is it that difficult to set up a head git repo? I’d argue
repo has a number of projects and the layout of the repo clearly
trunk
reasonable, but I was hoping to keep the all the Nitro projects under
one “roof” while having independent dev tracks at the same time.

The downside of a pure Git repo is that it would have to be hosted by
a private system (no public “forges” I know of support git) and also

Some git hosting sites:

things seem to be moving in the world of git, so it has probably
changed and is not exhaustive:
http://alioth.debian.org/
http://git.sv.gnu.org/gitweb/
http://repo.or.cz/

I’m hoping code.google.com would move sooner than later, but perhaps
they are waiting for git under Windows to mature…

anyone on Windows would not have access to the repo (maybe not that
big a deal, but something to be considered nonetheless).

Well, if cygwin counts as “Windows” then you running git under windows
is officially supported. A “Windows git” without cygwin maybe coming:

One can suggest people search on “WinGit” and “msysgit”, or even
provide direct links?
http://git.or.cz/gitwiki/WindowsInstall

Anyway, it seems there is a path so maybe this isn’t a git showstopper?

HTH
Mark

12

On Nov 30, 2007 9:10 AM, Judson L. [email protected] wrote:

better served if they were separated, with Nitro being a sort of
first-client for Og, in terms of testing, features, etc.

I think I posted a list of Ruby ORM projects some time ago - quite a
long list.
Og stood out as unique in the approach taken, and more general than
most others. DrySQL, MagicModels, Sequel and AR are notable too.
Obviously there will be niche segments that projects will occupy, but
I do wonder if there isn’t potential for efforts to coalesce?
Will that happen? That probably depends on how development occurs and
on how any community operates.

Exploring alternative ideas, individual initiative and innovation are
important.
My starting assumption is that, at the moment, less fractured ORM
development efforts could be a net positive.
I do wonder how Og under Nitro might accelerate and facilitate this?
Of course Og might be trageting a some niche, but from my reading of
the code it seemed to be more generalized than specialized.

Of course it might be that approaches are so different among ORM
projects that there is no melding possible, but from what I’ve seen in
the Sequel project that isn’t the case - though at the outset it
didn’t look too promising.

another 2c :wink:

Mark

13

On Nov 29, 2007 6:50 PM, Trans [email protected] wrote:

Well, I can give you another reason. I can set up an SVN repo up in
moments (with access to a rubyforge project) and get things rolling
right a way. the issues we have for setting up a git repo are some of
the same that we have with the darcs --George is the sole patch
gateway.

That’s a fantastic reason. I’m still in the camp of wanting Og to stand
on
it’s own, but a big part of that drive is getting more devs on a worthy
projects (self included). Having the repo be easier to access and
commits
be easier would be a huge step towards that.

Judson

14

On Nov 29, 5:10 pm, “Judson L.” [email protected] wrote:

first-client for Og, in terms of testing, features, etc.
Your subnet is currently 169.254.0.0/16. You are likely to be eaten by a
grue.

Well, I can give you another reason. I can set up an SVN repo up in
moments (with access to a rubyforge project) and get things rolling
right a way. the issues we have for setting up a git repo are some of
the same that we have with the darcs --George is the sole patch
gateway.

T.

15

On Nov 30, 2007 4:11 PM, Jonathan B. [email protected] wrote:

  1. Git
  2. Darcs
  3. Arch
  4. SVN

If we’re playing the favorites game, here’s my thinking.

My experience with darcs has been exclusively with Nitro. Workflow
looks
like: get the repo, make a change, check in, export a patch, send it to
the
list. Repeat from get the repo. Which is stupid, IMO, but trying to
just
update my local repo for Nitro more often than not destroys whatever
work
I’d done. Plus, pulling the repo yesterday, all of 47 patches took >
30minutes, and wailed on my proc for the whole time. To put it bluntly,
I’m
not a fan.

Looking at git, it looks okay. I haven’t used it, myself, but from what
I’ve read it’s strongly influenced by the design for Monotone, which I
do
use and like a lot. The biggest differences seem to be ease of use and
performance (the later, I think, won’t make much difference for a
project
the size of Og.) I’m always glad to have an opportunity to form a
reasonable opinion of an important technology.

SVN is simple, functional, and couldn’t be easier for us. Someone else
is
managing the repo, tools are widespread and mature. I’ve been using it
at
work for a while now and am comfortable with it, if not in love. This
single biggest advantage of SVN is that we could have a sensible repo
set up
pretty much Right Now, with dev branch(es) etc. At least, this is the
theory. I was looking earlier, and Nitro was created as CVS, which
would
mean getting the RF guys to switch it over - they’re good, but we’d
still
wait a day or two.

So, my list of favorites looks like:

  1. Monotone
  2. Subversion
  3. Git
  4. CVS
  5. Darcs
    (yes, really.)

Judson

16

Hi,

Anyway, it seems there is a path so maybe this isn’t a git showstopper?

as I have been doing some off ruby work lately, I also tried git, to
make the ‘start’ as fresh as possible.

And, I have to say, I’m really happy with git now.

  • Not quite as userfriendly as darcs

That is the only minus.

The biggest plus for me however is something kinda unrelated:

My repo is clean, always. With darcs I used to create changes here
and there, debug stuff together with new features and old bugfixes.
Recording is nice then of course with darcs, just skipping the rest,
but the repo is still messy.

With git it’s very much different. I can choose (due to the branches)
to work on this or that without copying the repo or cluttering it.

That is my biggest plus (besides the nice gitk <3 for code review) on
git, clean repo, less overhead for my mind.

My personal hitlist of version control systems would be:

  1. Git
  2. Darcs
  3. Arch
  4. SVN

Jo

17

On Nov 29, 2007 6:50 PM, Trans [email protected] wrote:

Well, I can give you another reason. I can set up an SVN repo up in
moments (with access to a rubyforge project) and get things rolling
right a way. the issues we have for setting up a git repo are some of
the same that we have with the darcs --George is the sole patch
gateway.

T.

So, SVN repo? What’s the status of getting this set up?

Judson