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.
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.
Tier : 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.
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.
Projects such as those Alfred thinks are more usual, have only
tiers and Three, with no Tier Two.
Since Tier two is in the same category as Tier one.
The result is that people who have not yet earned the confidence
that Tier 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. If
you trust someone to not hose the tree or cause trouble for others,
then they should be given commit access.
Alfred is incorrect that every other project has only Tiers and
Three.
I never claimed that, I can think of one notable example: gcc.
Tier Two people who want to be in Tier should just ask. At
this point, I think Alfred has proved his ability to do the
necessary tasks of Tier maintenance, and I would ask that if we
move him up to Tier , 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. ;)
1) He seemed to me to be saying that he was going to move from Tier
Two to Tier 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?)
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
Yes.
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.
No. Everyone should share the burden with each other. If I commit a
broken patch, and Marco complains, then I should fix it unless Marco
is cute enough to do it for me. The same goes for Marco, or anyone
else. Simple. It reduces the time to get good patches committed, and
it reduces the overall responsibility of a maintainer including the
burden without compromising the quality of patches that go in.
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).
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 I do not
accept that everyone in Tier Two should all be moved to Tier
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.
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. While in tier two systems people can still
work on stuff without getting bothered by the lazyness of the
maintainers.
Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

"Alfred M\. Szmidt" <ams (AT) gnu (DOT) orgwrites:

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.

If a person cannot make a decision, they should ask. That is the only
way to learn in my book. If they make a mistake, it is simply to fix
it, the whole reason why you have version control systems after all.

You don't understand what Tier Two is for. You are still mired in
thinking that it is a way to keep people out of Tier It's not.
Tier Two is just a group of Tier Three people who we know aren't going
to be malicious or destructive, nothing more.

We could do development the way a wiki is run. But while that's great
for some purposes, I'm not sure it's the most productive use of the
developers' time. Wiki's are not so good for interacting pieces of
stuff; an example is wikispecies which has yet to reach convergence
about some basic issues, and which requires consistency across a broad
spectrum of pieces to really be what it could be.

I have nothing against wikis, and perhaps even wiki-ish development of
software would work. But I don't want to try it here, with this
project.

If the group is silent, then only a single person can declare how
something should be done. As was the case for GNU Mach. Marcus
wouldn't have said a word if I hadn't poked him on IRC, nor would
you.

So you performed a service. However, the manner in which you poked,
whether intentionally or not, hurt me.

Thomas

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

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.

If a person cannot make a decision, they should ask. That is the only
way to learn in my book. If they make a mistake, it is simply to fix
it, the whole reason why you have version control systems after all.

We make that decision as a group, by consensus, and not by just one
person declaring the new way it will be.

If the group is silent, then only a single person can declare how
something should be done. As was the case for GNU Mach. Marcus
wouldn't have said a word if I hadn't poked him on IRC, nor would you.
If only one person cares enough, and nobody even cares enough to even
say anything, that is the only way to decide something. I don't
regret it, and would repeat it anyday of the week, and would expect
the same thing on a project where I am the maintainer and am simply to
lazy to even answer such a request.

So I'd rather see something like a Tier 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.

It isn't pointless, a commit-diff doesn't contain a description of
what the patch fixes. And a commit diff doesn't inline patches, grrr.

By the way, could you/Roland give Thomas Schwinge (savannah user
name tschwinge) commit access? I trust him enough not to ****
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.

Thanks.

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

"Alfred M\. Szmidt" <ams (AT) gnu (DOT) orgwrites:

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
disagree, then that is right there a good reason *not* to put you in
Tier 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 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 **** 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

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

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

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.

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.)

I wasn't thinking about Tier Three people, I was thinking about Tier
Two. It was simply a typo to mention Tier Three in there, since they
can't do anything anyway to the CVS tree.

The result is that people who have not yet earned the
confidence that Tier 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.

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.

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

They should have a stable vs development branch. libc head likes to
break on occasion to and I'm not refering to Hurdy bits there. I
don't actually mind if the tree doesn't build on ocassion in CVS. It
is a bit different for us since we don't have a release we can point
people to.

If it wasn't clear, by `ass chewed' I really meant a nice poke that
they should fix whatever they broke.

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 of the gnumach source, would you be small,
lazy, and unresponsive? I hope not

Depends on who you compare to.

So I'm happy to put you into Tier , 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.

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 actually trust
people to check that something works before I commit it (I do look
that the overall patch is K). And would expect that this would be
done if they commit it themselfs. The only time I think the
intervention from a tier one is really needed is if when one wishes to
commit something that is big, changes interfaces or something that one
is unsure of. I'm also not sure what kind of responsibility a tier
one has.

So I'd rather see something like a Tier 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).
And if the fix isn't correct (since a Tier looked at the patch),
they should fix it ASAP. So they should be more carefull than a Tier
, but not require explicity approval as a Tier Two. So for
example, a Tier Two person who has had commit access for say a year
(and has actually gotten patches in as is by a Tier on several
occasions) automaticlly get pushed into the Tier and a Half group.

By the way, could you/Roland give Thomas Schwinge (savannah user name
tschwinge) commit access? I trust him enough not to **** 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.

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

"Alfred M\. Szmidt" <ams (AT) gnu (DOT) orgwrites:

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 : 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 people!

Projects such as those Alfred thinks are more usual, have only
tiers 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

The result is that people who have not yet earned the confidence
that Tier 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 should just ask. At
this point, I think Alfred has proved his ability to do the
necessary tasks of Tier maintenance, and I would ask that if we
move him up to Tier , 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 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).

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 I do not
accept that everyone in Tier Two should all be moved to Tier
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 of the gnumach source, would you be small,
lazy, and unresponsive? I hope not

So I'm happy to put you into Tier , 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

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org