bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

commit access policies


From: Thomas Bushnell BSG
Subject: commit access policies
Date: Sat, 12 Nov 2005 14:24:31 -0800
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]