bug-hurd
[Top][All Lists]
Advanced

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

Re: commit access policies


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

"Alfred M\. Szmidt" <address@hidden> writes:

> I really dislike having a bunch of branches for each and every person.
> Either have a generic branch for tier twos (like ams-branch), or have
> a branch based on a major feature that is being worked on.

If you want to suggest the creation of a specific branch for a
specific purpose, I'm all for it.

>    Tier One: Full access.
>
> There is only one person with full access right now, Roland.  Not even
> you belong here I think (Roland did bite your ass once or twice when
> you commited something, though I do not recall the circumstances so
> maybe you do belong there), Marcus also doesn't belong to this class.

Actually, I do still have full access.  I recognize that it would be
unwise for me to be using it without a stronger commitment and
intention than I have at present.

>    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.
>
> I think this should be asked from anyone with commit access, be it
> tire three, tire two or tire one.

You must have misunderstood.  People in Tier Three do *not* need to be
trusted with these things, because they cannot abuse cvs access, not
having any.  (By "hose the CVS server" I meant things like checking
spam in, or checking in ginormous files, not just a run of the mill
DoS attack.)

Certainly, everything here is also expected of Tier One people!

>    Projects such as those Alfred thinks are more usual, have only
>    tiers One and Three, with no Tier Two.
>
> Since Tier two is in the same category as Tier one.

No, not quiet.  Many of the people in Tier Three on such projects
would be in Tier Two in ours.  We can put people into Tier Two that we
do not trust to be in Tier One.

>    The result is that people who have not yet earned the confidence
>    that Tier One implies have to be denied commit access entirely.
>
> You put a to strong weight on what Tier one should imply.  Not hosing
> the tree, and causing trouble for other is quite good cirteria for
> anyone who has commit access no matter what Tier they belong to.  

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.  

> If you trust someone to not hose the tree or cause trouble for
> others, then they should be given commit access.

You have misunderstood what I'm speaking of, I think.

>    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.
>
> I almost feel insulted, since I have been doing that burden of
> reviewing patches for the past few years, not you. ;)

And your ability to do that well is exactly why I made this
> suggestion. 

>    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.
>
> No, if it was my own say-so alone then I would have been committing
> things to the GNU Mach 1.x tree already.  It was on the say-so of the
> lack of a say-so from the maintainers.  But since there was a say-so
> from someone who isn't even the maintainer, the claim that it was done
> on my own say so is simply false.
>
> (Does that make sense?)

Yes, but a lack of say-so does not translate into say-so.  If you
interpret an inability to respond immediately or promptly as consent,
we have a problem.  Some things we want positive confirmation for.
Changing commit access, for example, is such a thing.

>    But this goes along with Alfred *not* deciding that he can
>    eliminate Tier Two on his say-so alone.
>
> I have done that for ams-branch.  I hope you will not dictate what
> kind of policies I can set for "my" branches (I do not consider
> ams-branch my branch, despite the name of the branch).

Of course not, that's the whole *point* of having a Tier Two.

>    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.
>
> Why not?  They should be willing to get their asses chewed if they
> commit something that is simply broken or unacceptable.  And
> revert/fix whatever they broke.  And if they continue to be silly they
> should get a warning (like committing totally unteseted patches all
> the time), then they should really hide somewhere.  It once again
> boils down to taking responsibility for whatever you commit.

I do not want people getting their "asses chewed".  Gnucash
development is occasionally hosed because maintainers with commit
access check things in that break builds for other people

> So yeah, I prefer a two tier based system over three tier based
> systems, since in tier three based system tier one is utterly small,
> lazy, and unresponsive.  

If you are in Tier One of the gnumach source, would you be small,
lazy, and unresponsive?  I hope not...

So I'm happy to put you into Tier One, if Roland agrees (I'll poke him
myself if he doesn't pop his own head up shortly), but a condition of
that is that you don't start declaring Tier Two empty on your own
hook.


Thomas




reply via email to

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