geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject commit privs (was: geronimo-dev Digest 13 Aug 2003 16:44:13 -0000 Issue 47)
Date Wed, 13 Aug 2003 20:47:27 GMT
On Wed, Aug 13, 2003 at 04:44:13PM -0000, geronimo-dev-digest-help@incubator.apache.org wrote:
>...
> From: Berin Loritsch <bloritsch@apache.org>
> Subject: [Fwd: Commit privileges]
> To: geronimo-dev@incubator.apache.org
> Date: Wed, 13 Aug 2003 12:33:52 -0400
>...
> So how does one go about getting commit privileges here anyway?
> I don't even know who has them and who doesn't.  I'd like to hack
> away fine-tuning the kernel code or help with the component model,
> but the diffs will undoubtedly be a bit messy.  Furthermore, it is
> difficult to show how an experiment works when it is only on your
> machine.
> 
> What would be the best way to go about this?  We can talk till we
> are blue in the face, but until there is some action/proof of our
> claims most people will continue to argue that their bike shed color
> is better.  Not wanting to be one who simply talks, I'd like to put
> forth some action.

The Apache Geronimo project has a *lot* of people interested here, and I
believe that one of the things which needs to happen is scaling up the
committer base, which then allows the project to scale up.

In most ASF projects, people are voted in as committers if they demonstrate
several qualities:

  1) their patches [which they've posted] demonstrate coding competence
  2) their discussion demonstrates a good ability to work with others
  3) their vision aligns with the rest of the community

When the Incubator bootstraps a project, we simply need to assume that
points (1) and (2) are true, and the initial committers are the people who
initially define (3) until a larger community forms and begins to steer
<wherever>.

Also note that for people such as Berin, coming from other ASF projects,
there is a "lower bar" for demonstrating (1) and (2). The assumption is that
those bars have already been crossed. Also, candidates for commit ability
usually come from other open source projects, so people familiar with those
other efforts will usually tend to vote +1 based on that (external) work.
Just be wary about how the external projects are run, relative to how the
ASF likes to see projects run (this impacts the decision around (2)). (and
for some definition of "how ASF likes to see projects run" :-)

I'd also point to something that we do in the Subversion project which has
proven to be very successful. We have a very low bar for committers for
*specific* areas, if that person has demo'd themselves for that area. We
apply much more rigor in the decision process for "blanket commit access."
When somebody gets "limited" access, we merely ask them "you're free to
commit to <this> area; if you want to commit to elsewhere in the Subversion
project, just get a +1 or two from full committers and go ahead an apply
your own patch." We find that simple social dynamics will keep people
committing to the proper areas; we haven't had any problems with people
patching "out of bounds".

To make that concrete for Geronimo: there have been patches from people who
are creating test cases. I'd say to give them commit access for adding test
cases. The standard rules would still apply for access to the "full"
Geronimo codebase, but in the meantime, you don't have to worry about
continually applying test case patches.
[ of course, the new committer would need to submit a CLA, as usual ]

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message