harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <m...@leosimons.com>
Subject SableVM? -- commit privileges? (was: Contributing SableVM?)
Date Thu, 23 Mar 2006 08:35:43 GMT
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

Mime
View raw message