(damn thread hijackers.... :)
Leo Simons wrote:
Very cool. Besides how cool it is to see this happening, its also amazing
at which speed its happening.
On Thu, Mar 23, 2006 at 01:28:38AM -0500, Etienne Gagnon wrote:
Geir Magnusson Jr wrote:
<snip type="ip stuff" />
1) Donate the code, submit patches, earn commit.
Hmmm... Do I really have to earn commit rights to SableVM? Sincerely,
I do not think that this would be reasonable for some key SableVM
developers.
Personally, I agree. We sort-of "know you" by now through e-mail
interactions and purely based on that (and looking at some of the
SableVM development history) I trust you enough.
I added this option only for completeness. Notice it was my choice #3.
I never advocate this model.
2) Donate the code, and some number of people come in with it with
commit granted to the "sableVM" part of the repository, and interaction
with the other parts of the codebase are done via patch until earned.
All existing committers have full access, but simple manners would
dictate we wouldn't go barging into code we don't understand.
In the SableVM repository, only a few contributors have commit rights to
the trunk. I see no trouble on having other SableVM authors earn their
commit right; this is already how we proceed.
Currently, there are only two commiters to the SableVM trunk:
- Grzegorz Prokopski
- Me
Two people is in many ways different from 18, or 27, in terms of how
"disruptive" it might/could be to the "dynamics" of development.
3) Donate the code, some # of people come in w/ full commit.
Greg and me are unlikely to modify much code in the class libraries.
We're VM developers, not class lib developers. Yet, my worry is that
not having access to the class library side of the VM interface might be
quite limiting, to say the least. I would say that access to LUNI is
probably a must, under some restrictions (see below).
Both Greg and me have a long experience with class library maintenance
and Subversion. We've been taking care of the maintenance of the
SableVM/Classpath VM interface, and of fixing some sablevm-classpath
bugs from while to while.
I don't see myself starting to commit anything in the class library code
(including the VMI) without first discussing it on this list. Actually,
I would first have a working copy of it available my sandbox, in the
SableVM svn repository, for Harmony developers to look at and test.
So, how about the following: We go with some hybrid of your options #2
and #3. The number of "automatic commiters" is limited to two
developers: Greg and me. To commit anything outside the SableVM code,
Greg and me must first discuss it on this list, and get the consent of
Harmony developers. The right to commit obvious little patches and
improvements outside the sablevm code, without prior discussion on this
list, must be earned.
Different ASF communities use lots of different rules/models about how the
trunk can and cannot be changed. For example, some projects (notably
HTTPD) have a "review-then-commit" policy, where *everyone* *always* needs
to send *every* patch to the mailing list for review (eg getting a +1)
before they're allowed to commit it. Mozilla is an example where there is
even more strictness (they have "super-review" too).
One day, we may actually get there - if we become *the* implementation
of Java SE, then we will go this way. There would be far too much at
stake to not have a process like that. Right now, there is no point.
This is usually somewhat seperate from actual access rights, which can be
convenient at times. How to go about committing different things to
different files of different parts of the repository is not so easily
codified in rules. For example, I highly doubt you would have any kind of
problem with me committing a mass-reformat of the license headers on files
in the what-would-be SableVM trunk. I would assume I'm trusted to know what
I'm doing in such a case.
In my mind, these kinds of things are supposed to be based on trust. Once
you "trust" that you "have the trust" of the other people working on the
codebase, you might sometimes agree to switch to a commit-then-review way of
working from the original review-then-commit mechanism. But "trust" is
something very hard to codify in some kind of "policy", let alone in access
control rules.
So I think I would actually prefer option #3 (with the # of people == 2, not
27), with the shared understanding that no-one goes around making a mess of
things or impacting existing workflow.
Some people around the ASF have spent near-insane amounts thinking about
this kind of thing and I'm one of them. Still not done with the thinking :).
With every passing year I drift more and more towards a its-not-the-rules-its-
how-you-apply-them kind of idea.
I understand and sympathize with what you are saying, but I think that
#2 reflects sensitivity for those in the community that are earning
their full commit status "the old fashioned way".
That's why I suggested #2 - people keep working on SableVM w/o any of
the hassle of patches, but full commit is earned over time like everyone
else.
geir
