SableVM? -- commit privileges? (was: Contributing SableVM?)

[Leo Simons <ma...@leosimons.com>]

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.

> > 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).

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 am sure that we will need a period of adaptation, on both sides.

yup.

>  I anticipate discussions on how to setup the SableVM code in the Harmony
> repository so as to make sure that the coding style match the Harmony
> coding style, and on which tool dependencies are OK or not, etc. 

and the other way around :-)

> So, I
> don't see Greg and me randomly changing code in the SableVM code without
> first discussing any significant change on this list.  Yet, I see no
> reason for us to "earn" the right to fix a little interpretation engine
> bug, for example.

Very much agreed.

> Would this be OK?

I think how all of us think about this kind of stuff is in the end compatible.
Getting all the actual "rules" and "mechanisms" "right" is hard and will take
time and effort.

What do others think?

- Leo

Re: SableVM? -- commit privileges?

[Geir Magnusson Jr <ge...@pobox.com>]

(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