Fu(*ing Reply-To: :) -----Original Message----- From: Scott Sanders Sent: Wednesday, October 23, 2002 8:40 PM To: 'Greg Stein' Subject: RE: veto rights (was: Naming issues)
> > > The 'intent' (IMHO, of course) of the j-c commit > > > model, was that everyone had avail access to all > > > code, but you had to add yourself as a member of the > project before > > > you committed to it. This was ultimately end run where > people would > > > just add themselves and then veto, > > Yup, I can see that, and your comment that it actually > occurred causes me worry. The merit-based approach that I > described is designed specifically to inhibit such behaviors. Which is ironic, because if Costin hadn't done just this on commons-logging and to some extent commons-discovery, we would have much less useful code today. He stood up and said 'You guys have a good idea here, but you're really fucking it up!' He pissed us off getting his point across, but it actually made the code better in the end. > > [ well, "designed" is a bit strong... you could say it > evolved and is part > of the basis for that nebulous term "Apache Way" -- you > only get to vote > if you're an active participant ] I understand exactly what you are saying, and agree. I just can't help but disagree as well :) > > > The most useful thing here is that since j-c has so > > > many smaller projects (in terms of code size), that anyone willing > > > to review and commit a patch is a good thing. If you don't know > > > much about the component, you don't commit the patch, but if you > > > have a good idea about, but just not the bandwidth > > > to completly participate, commit the patch. Some > > > may disagree with this, but I am a firm beleiver, as > > > the codebase size approaches zero. > > Yes, this can be handy for small codebases. I might respond > that the correct answer is to aggregate those codebases. You > end up turning 10 small bits, each with one committer, into a > larger group where patch review and application can be shared > by 10 people. And I think this is *exactly* what jakarta-commons is. A separately released, aggregate codebase where everyone is watching out for everyone else. That part actually works quite well. I can see that this may not work as jakarta-commons grows, or because of the language-agnostic nature of apache commons. > > Let's look at your comment in a bit more detail: > > * "anyone willing to review and commit a patch is a good thing" > > The more, the merrier, yes. And anybody *can* review a > patch. You don't > have to be a committer to do that. In fact, doing this is a > step towards > earning your commit rights. It can show how you work with > others, that you > have interest in the codebase, that you be constructive, > and that you're > willing to spend the time. > > The part about committing is trickier, though. "anyone" can > create real > problems, as I've explained elsewhere. A drive-by committer > might not > understand enough to be responsible for the commit. Worse, > they might not > realize that, think they know what is up, and commit away... Agreed, but CTR could work its magic here. > > * "if you don't know much about the component, ..." > > This rule is easily handled by the merit-to-commit rule. > Your demonstrated > knowledge of the component gets your commit privs. If you don't know > anything about the component, then you're already denied > the ability to > commit patches. > > * "if you have a good idea about, but just not the bandwidth > to participate, > commit the patch" > > This one is a bit tougher. If you've earned the commit > privs in the past, > but aren't participating much any more, then this can be a > good thing. > You have one more person who can help the project. Of > course, lack of > active participation might also mean you suffer bit rot, > and fall into > the "not knowing" category, but it is best to assume that > any previous > committer is still competent. (i.e. once you're in, then > you're in for > life :-) > > The harder problem is the relatively inactive person who > probably knows > their stuff, but hasn't demonstrated particular > interest/merit for the > given component. How do you take advantage of their time > and inclination > to apply patches? > > a) too bad, the patch just sits idle > > b) lower your bar for officially granting commit privs > (the PHP people do > this to great effect) I think might work extremely well. Sam Ruby brought this attitude over to Jakarta, and that is why I am a committer today. I'm a big +1 on this. > > c) depending upon the karma setup (CVSROOT/avail), the > person might have > the technical ability (but not the Right) to do the > patch; but a real > committer might say, "looks good. can you handle applying it?" True, this could work great this way. Your thoughts are great on the subject, Greg. I am just attempting to present what I see is 'right' with j-c IMHO. Scott
