On Tue, 16 Nov 1999, Guido van Rossum wrote:
... Greg, I understand you have checkin privileges for Apache. What is the procedure there for handing out those privileges? What is the procedure for using them? (E.g. if you made a bogus change to part of Apache you're not supposed to work on, what happens?)
Somebody proposes that a person is added to the list of people with checkin privileges. If nobody else in the group vetoes that, then they're in (their system doesn't require continual participation by each member, so it can only operate at a veto level, rather than a unanimous assent). It is basically determined on the basis of merit -- has the person been active (on the Apache developer's mailing list) and has the person contributed something significant? Further, by providing commit access, will they further the goals of Apache? And, of course, does their temperament seem to fit in with the other group members? I can make any change that I'd like. However, there are about 20 other people who can easily revert or alter my changes if they're bogus. There are no programmatic restrictions.... You could say it is based on mutual respect and a social contract of behavior. Large changes should be discussed before committing to CVS. Bug fixes, doc enhancements, minor functional improvements, etc, all follow a commit-then-review process. I just check the thing in. Others see the diff (emailed to the checkins mailing list (this is different from Python-checkins which only says what files are changed, rather than providing the diff)) and can comment on the change, make their own changes, etc. To be concrete: I added the Expat code that now appears in Apache 1.3.9. Before doing so, I queried the group. There were some issues that I dealt with before finally commiting Expat to the CVS repository. On another occasion, I added a new API to Apache; again, I proposed it first, got an "all OK" and committed it. I've done a couple bug fixes which I just checked in. [ "all OK" means three +1 votes and no vetoes. everybody has veto ability (but the responsibility to explain why and to remove their veto when their concerns are addressed). ] On many occasions, I've reviewed the diffs that were posted to the checkins list, and made comments back to the author. I've caught a few problems this way. For Apache 2.0, even large changes are commit-then-review at this point. At some point, it will switch over to review-then-commit and the project will start moving towards stabilization/release. (bug fixes and stuff will always remain commit-then-review) I'll note that the process works very well given that diffs are emailed. I doubt that it would be effective if people had to fetch CVS diffs themselves. Your note also implies "areas of ownership". This doesn't really exist within Apache. There aren't even "primary authors" or things like that. I have the ability/rights to change any portions: from the low-level networking, to the documentation, to the server-side include processing. Of coures, if I'm going to make a big change, then I'll be posting a patch for review first, and whoever has worked in that area in the past may/will/should comment. Cheers, -g -- Greg Stein, http://www.lyra.org/