Currently we are using a three-tiered model for commit access: Tier Three: Anyone in the world, who is free to submit patches for consideration.
Tier Two: People who have bits to commit to the archive, and can have their own branches, but should only commit pre-approved patches to the main trunk. Tier One: Full access. The advantage of this model is that people who are trusted to follow the commit policy, who can be trusted not to hose the CVS server or raise major headaches for maintenance, can be given commit access in Tier Two. This reduces the work of adding their patches in (because they can do it themselves) and makes it easier to share work between their branch and the main branch. For Tier One, people must be sure of a lot more: that committers know which things should have broad discussion before being committed and which do not need that; that committers are disciplined about committing untested or uncompilable patches; that committers are good at reviewing their own work before committing it; that they have enough knowledge of the full codebase to make confident and correct judgments about what code is good and what is bad. Projects such as those Alfred thinks are more usual, have only tiers One and Three, with no Tier Two. The result is that people who have not yet earned the confidence that Tier One implies have to be denied commit access entirely. Alfred is incorrect that every other project has only Tiers One and Three. The libc project has the same three tiers (or used to); indeed, it had more than that, because port maintainers were in Tier One with respect to their own directories in the source, but Tier Two with respect to everything else. When I worked for Project Athena, *nobody* was in Tier One: Nobody, not even the release manager. Tiers Two and Three were well populated. (Indeed, I think I still have commit access bits, even though I haven't worked there for six years.) We do not have to continue to have Tier Two, but I think it has useful flexibility. Tier Two people who want to be in Tier One should just ask. At this point, I think Alfred has proved his ability to do the necessary tasks of Tier One maintenance, and I would ask that if we move him up to Tier One, he agree to start shouldering the burden of reviewing patches from those in tiers Two and Three. We should decouple the question of "should Alfred be in Tier One" (for which I think "yes" is a fine answer) from the question "should we drop Tier Two." What raised my hackles about Alfred's email was a combination of three things: 1) He seemed to me to be saying that he was going to move from Tier Two to Tier One on his own say-so alone. 2) He seemed to me to be saying that at the same time he was going to declare that everyone in Tier Two was now in Tier One. 3) He seemed to me to be saying that he was not willing to shoulder the burden of maintainership or reviewing patches at the same time. If I am incorrect in these judgments, I apologize. I am happy to declare Alfred in Tier One now (but it is not my decision alone to make). But this goes along with Alfred *not* deciding that he can eliminate Tier Two on his say-so alone. This is *exactly* the sort of question that requires agreement among many, not just one person's say so. If we are to eliminate Tier Two, then we need to go through the existing people in that class, one by one, and decide which should be moved to Three and which should be moved to One. I do not accept that everyone in Tier Two should all be moved to Tier One without any review. Thomas _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
