On Wed, Aug 13, 2003 at 04:44:13PM -0000, [EMAIL PROTECTED] wrote: >... > From: Berin Loritsch <[EMAIL PROTECTED]> > Subject: [Fwd: Commit privileges] > To: [EMAIL PROTECTED] > 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/
