Re: commit access policies

[Thomas Bushnell BSG]

"Alfred M\. Szmidt" <ams@gnu.org> writes:

> I atleast don't see any need for a specific branch right now, I wanted
> ams-branch to have a generic name (devel-branch), but Roland disliked
> that.  In either case, I consider it generic.

I dislike the name "devel-branch" because it isn't specific enough to
describe the branch.  A named branch is convenient, because the casual
looker can immediately know who is responsible.  Sometimes if a branch
is there to accomplish a specific task, then it's good to name it for
that task.

>    No, if you do not check things in to the main branch, then you
>    cannot break the main branch, no matter what disastrous things you
>    do elsewhere.
>
> Uhm, but Tier Two people can do exactly that.  They have earned the
> confidence not to screw up the main branch (or any other branch),
> unless someone approved the change.  They can still screw it up, but a
> limb or two might be missing after the act.

You are confusing two different kinds of trust.  

I can trust someone to follow agreed rules and not to be malicious.
That's what it takes for Tier Two.  But that's a far cry from trusting
them to be technically competent, not make certain kinds of mistakes,
and the like.

At MIT Athena, for example, everyone on staff could be trusted to
follow agreed rules and not be malicious.  But we had a commit policy
in which *everyone* was in Tier Two.  We didn't want any changes
committed without two sets of eyes looking at them, so (except for
very special cases) any commit only happens once someone has reviewed
and okayed it.  The set of reviewers is the "release team", but anyone
could contribute patches, and anyone with commit access (a much larger
set than the release team) could commit.  But not even the release
team, not even the release manager himself, could commit without a
second approval.  This policy served that environment very well.

It is very important to separate "trust so-and-so not to make certain
kinds of mistakes" from "trust so-and-so not to deliberately cause
trouble or violate policies".

> I'm still not happy about it.  The reason is that I will get _all_ the
> burden (simply because I am the most responsive).  

I'm not sure how that's worse.  You could still simply not respond.

Your choice right now is between:
A  three tiers, with you in tier two
B  three tiers, with you in tier one

I understand why you want:
X  two tiers, with you in tier one

The question of whether we should move to (X) is not the same thing as
(A) to (B).  Moreover, if you say that your first action in tier one
would be to force us to (X) even if the other people in Tier One
disagree, then that is right there a good reason *not* to put you in
Tier One.  We make that decision as a group, by consensus, and not by
just one person declaring the new way it will be.

> So I'd rather see something like a Tier One and a Half group of people
> who can commit stuff, but they should send a message to bug-hurd with
> the patch, what it does etc before commiting it (atleast for gnumach,
> I don't care much for hurd HEAD since the creation of ams-branch).

This is pointless; anyone who wants can get commit-diffs mailed.

> By the way, could you/Roland give Thomas Schwinge (savannah user name
> tschwinge) commit access? I trust him enough not to fuck things up,
> and he has done most of the dirty work when it comes to patches and
> would be a immense help for me atleast.

I agree.  I'll poke at it.

Thomas