harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: SableVM? -- commit privileges?
Date Thu, 23 Mar 2006 23:33:09 GMT
(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 


View raw message