[gentoo-dev] Glep 48 update (as nominated for next meeting)

[gentoo-dev] Glep 48 update (as nominated for next meeting)

[Tomáš Chvátal]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,
first off i would like to apologize for not sending this mail sooner
(helluva week).

So draft we would like to have implemented as Glep update is this diff:
http://dev.gentoo.org/~scarabeus/glep-0048.diff

Please comment and help us improve the "english" of the whole document
so it gets accepted :)

Cheers

Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1DMQIACgkQHB6c3gNBRYdXPgCgu0/rITuXTPLkngR/CMVVjXs3
hx0AnAxONMKBw1fRR27V1RdA5Hx/rk4/
=xSmN
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Glep 48 update (as nominated for next meeting)

[Rich Freeman]

2011/1/28 Tomáš Chvátal <scarabeus@gentoo.org>:
> So draft we would like to have implemented as Glep update is this diff:
> http://dev.gentoo.org/~scarabeus/glep-0048.diff
>
> Please comment and help us improve the "english" of the whole document
> so it gets accepted :)

My only general comments are:

1.  It makes sense that in the event that a "Rogue" developer is
wreaking havoc on the tree that QA can get infra to suspend their
commit rights.  That's safeguarding the tree in the face of imminent
harm.  This should generally be limited to serious issues (people
running scripts to mass-update packages, bad changes to system
packages, etc), and not because there is some dispute over whether
some obscure package should or should-not be masked.

2.  I don't think it makes sense for QA to discipline developers
permanently in these cases.  They should suspend access pending Devrel
resolution of the issue.  Devrel should of course strongly consider
the input of QA.

If Devrel is not adequately doing its job then this should be
escalated to the Devrel lead, or if necessary to the council (who can
step in if truly necessary).  In the face of imminent harm QA can
always get a temporary ban on commits from infra.  If this goes back
and forth (QA banning, Devrel unbanning) then I'm sure the council
will step in.

So, in a nutshell here is how it works:

1.  Developer starts messing something up (some crazy script is
committing junk to the tree, or dev is making some change to critical
package, or whatever).
2.  QA notices, or is told, or whatever.
3.  QA tries to ping dev - with severity of problem dictating how long
they should wait to resolve directly.
4.  QA determines that dev is unwilling to resolve a critical issue,
or cannot be reached and the matter can't wait.
5.  QA contacts infra, and infra suspends commit access to contain the damage.
6a.  QA initiates repairs (whatever this takes - they don't need to
personally do the work, etc).
6b.  QA logs complaint with DevRel.
7.  Devrel follows their process to resolve issue.  Developer remains
banned until Devrel feels they can be unbanned, or dismissed.  Devrel
takes input from QA.

If the issue here is that the Devrel and QA leads differ as to some
matter of policy or whatever, the council should be asked to resolve.
While the QA and Devrel teams may tend to self-govern, I don't think
the intent is that we end up having "three" Gentoos - the one ruled by
Devrel, the one ruled by QA, and the one ruled by the Council (not to
mention the Trustees).

In practice I haven't really seen any situations where we're really
having problems over this, so I don't want to start a war over
something that isn't even a problem.

In any case, the solution for developers is simple:

1.  Don't do stupid stuff to the tree such that you tick EVERYBODY off.
2.  If you want to do something to the tree that you think is right
but which might tick a lot of people off (whether they are QA or not),
post notice of it in -dev first.
3.  If you and QA can't work it out before you do it, then work it out
with the council or something.
4.  Generally act like an adult.  :)

Ok, that was probably overly verbose.  I don't see any issues with the
wording in the diff - this is more a matter of which is the right
policy.

Finally, if Devrel, QA, and the Council have already talked this out
and agree that QA is in the best place to police technical commit
issues, then pipe this email to /dev/null...

Rich

Re: [gentoo-dev] Glep 48 update (as nominated for next meeting)

[Tomáš Chvátal]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dne 28.1.2011 23:42, Rich Freeman napsal(a):
> 2011/1/28 Tomáš Chvátal <scarabeus@gentoo.org>:
>> So draft we would like to have implemented as Glep update is this diff:
>> http://dev.gentoo.org/~scarabeus/glep-0048.diff
>>
>> Please comment and help us improve the "english" of the whole document
>> so it gets accepted :)
> 
> My only general comments are:

Wow what a nice and long reply, thanks :)

> 
> 1.  It makes sense that in the event that a "Rogue" developer is
> wreaking havoc on the tree that QA can get infra to suspend their
> commit rights.  That's safeguarding the tree in the face of imminent
> harm.  This should generally be limited to serious issues (people
> running scripts to mass-update packages, bad changes to system
> packages, etc), and not because there is some dispute over whether
> some obscure package should or should-not be masked.
> 
> 2.  I don't think it makes sense for QA to discipline developers
> permanently in these cases.  They should suspend access pending Devrel
> resolution of the issue.  Devrel should of course strongly consider
> the input of QA.
> 
QA is not to discipline any developers. Everyone of us can cause
breakage, heck even i killed profiles once :)
Only case where we don't want Devrel interfere with QA decision at all
is when someone Intentionaly breaks main tree. Seriously if someone
really hit this issue i don't actually want him to apologize to another
team and pretend like it never happened, i would prefer him long gone in
a place far far away :) We really just want keep control over removing
access for people that does breakage to main tree just for the breakage
itself, aka it can't be excused in any way.
"""
Lets say you have this change for eclass which affects large part of the
tree and on -dev ml people including QA members told you not to do so,
yet you still proceed with the commit thus breaking part of the main
tree in effect.
In this situation normal accidental breakage or uneducated commit can't
count in cause you were told of that it is not the way you should do it.
So only way it can be described is deliberate act of main tree destruction.
Since QA team is responsible for overall quality of main tree it is
obvious we as team can't trust such person while he (or she) does not
listen to us. So we would like to be the ones who decide that they
should not be permitted to do direct commits to main tree. (they for
sure can stay developers and write documentation and help in other areas
they want to)
"""

> If Devrel is not adequately doing its job then this should be
> escalated to the Devrel lead, or if necessary to the council (who can
> step in if truly necessary).  In the face of imminent harm QA can
> always get a temporary ban on commits from infra.  If this goes back
> and forth (QA banning, Devrel unbanning) then I'm sure the council
> will step in.
> 
> So, in a nutshell here is how it works:
> 
> 1.  Developer starts messing something up (some crazy script is
> committing junk to the tree, or dev is making some change to critical
> package, or whatever).
> 2.  QA notices, or is told, or whatever.
> 3.  QA tries to ping dev - with severity of problem dictating how long
> they should wait to resolve directly.
> 4.  QA determines that dev is unwilling to resolve a critical issue,
> or cannot be reached and the matter can't wait.
> 5.  QA contacts infra, and infra suspends commit access to contain the damage.
> 6a.  QA initiates repairs (whatever this takes - they don't need to
> personally do the work, etc).
> 6b.  QA logs complaint with DevRel.
> 7.  Devrel follows their process to resolve issue.  Developer remains
> banned until Devrel feels they can be unbanned, or dismissed.  Devrel
> takes input from QA.
You actually pretty well described how we work when somebody breaks main
tree without its primary intention to nuke it off. Which is still in
effect with this update :) (everyone can make typo or forget to ask
about something and accidentally do something disasterous :P)

"""
+* In case a particular developer persistently causes breakage, the QA
+  lead may request commit rights of given developer to be suspended by
+  the Infra team. Devrel should then proceed to evaluate the situation, by
+  finding a compromise or permanently revoking those rights.
"""
> 
> If the issue here is that the Devrel and QA leads differ as to some
> matter of policy or whatever, the council should be asked to resolve.
> While the QA and Devrel teams may tend to self-govern, I don't think
> the intent is that we end up having "three" Gentoos - the one ruled by
> Devrel, the one ruled by QA, and the one ruled by the Council (not to
> mention the Trustees).
> 
> In practice I haven't really seen any situations where we're really
> having problems over this, so I don't want to start a war over
> something that isn't even a problem.
> 
> In any case, the solution for developers is simple:
> 
> 1.  Don't do stupid stuff to the tree such that you tick EVERYBODY off.
> 2.  If you want to do something to the tree that you think is right
> but which might tick a lot of people off (whether they are QA or not),
> post notice of it in -dev first.
> 3.  If you and QA can't work it out before you do it, then work it out
> with the council or something.
> 4.  Generally act like an adult.  :)
> 
> Ok, that was probably overly verbose.  I don't see any issues with the
> wording in the diff - this is more a matter of which is the right
> policy.
> 
> Finally, if Devrel, QA, and the Council have already talked this out
> and agree that QA is in the best place to police technical commit
> issues, then pipe this email to /dev/null...
Yep QA is responsible for technical aspect of commits where Devrel
handles the human side of it, so we usually give what we gather on named
bad developer to Devrel to decide what to do with him.
> 
> Rich
> 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1DS0UACgkQHB6c3gNBRYcVFgCdHxzgXCepKzj0SY3oWCaKQpKR
yDYAnj6Wg1Ew7Y8xtypkUXeoQ699/MNf
=J775
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Glep 48 update (as nominated for next meeting)

[Roy Bamford]

[-- Attachment #1: Type: text/plain, Size: 1268 bytes --]

On 2011.01.28 23:03, Tomáš Chvátal wrote:

[snip]
> Only case where we don't want Devrel interfere with QA decision at 
> all
> is when someone Intentionaly breaks main tree. Seriously if someone
> really hit this issue i don't actually want him to apologize to
> another
> team and pretend like it never happened, i would prefer him long gone
> in
> a place far far away :) We really just want keep control over 
> removing
> access for people that does breakage to main tree just for the
> breakage
> itself, aka it can't be excused in any way.
> """
[snip]

Its not QAs decision, if the breakage was intentional or not.  A single 
body, in this case, QA, cannot be both the police and the judicary.

QA can and should be capable of finding wrongs, preventing further 
damage and causing the problem to get fixed. Thats damage limitaion.
If preventing further damage involves revoking commit rights pending 
full investigation, thats fine by me.

Determining the root cause, and determining long term prevention takes 
some investigation. QA may present evidence but its Devrels job to 
weigh the evidence and pass sentence.

> Tom
> 


-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
gentoo-ops
forum-mods
trustees

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Glep 48 update (as nominated for next meeting)

[Jeroen Roovers]

On Sat, 29 Jan 2011 00:05:48 +0000
Roy Bamford <neddyseagoon@gentoo.org> wrote:

> Its not QAs decision, if the breakage was intentional or not.  A
> single body, in this case, QA, cannot be both the police and the
> judicary.
> 
> QA can and should be capable of finding wrongs, preventing further 
> damage and causing the problem to get fixed. Thats damage limitaion.
> If preventing further damage involves revoking commit rights pending 
> full investigation, thats fine by me.

> Determining the root cause, and determining long term prevention
> takes some investigation. QA may present evidence but its Devrels job
> to weigh the evidence and pass sentence.

Thank you for that. What in the recent past has perspired is that QA
has its place, after the fact, and that whoever feels to be in place to
deal out QA (and I think this has gone wrong a few times recently) is
required to:

1) state and/or explain policy specifically where it is being not
adhered to;
2) offer alternatives where policy is not adhered to.

There should be no way that someone in the QA team could be above
any /other/ developer. Anyone who is a developer is one, and anyone in
the QA team still has the same hierarchical place. If there are QA
issues, then logical and technical arguing should suffice - not some
perceived hierarchy derived from being in some team. Thank you.


     jer

Re: [gentoo-dev] Glep 48 update (as nominated for next meeting)

[Roy Bamford]

[-- Attachment #1: Type: text/plain, Size: 514 bytes --]

On 2011.01.29 05:20, Jeroen Roovers wrote:
[snip] ...
> and that whoever feels to be in place to
> deal out QA (and I think this has gone wrong a few times recently) is
> required to:
> 
> 1) state and/or explain policy specifically where it is being not
> adhered to;
> 2) offer alternatives where policy is not adhered to.
> 
[snip] 
>      jer
> 

Which is another way to say that QA is everyones job.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
gentoo-ops
forum-mods
trustees

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Glep 48 update (as nominated for next meeting)

[Fabian Groffen]

On 28-01-2011 22:11:30 +0100, Tomáš Chvátal wrote:
> So draft we would like to have implemented as Glep update is this diff:
> http://dev.gentoo.org/~scarabeus/glep-0048.diff
> 
> Please comment and help us improve the "english" of the whole document
> so it gets accepted :)

(:Nread http://dev.gentoo.org/~scarabeus/glep-0048.diff)
> --- glep-0048.txt	2006-09-05 22:45:04.000000000 +0200
> +++ glep-0048.new.txt	2011-01-25 13:49:38.525343000 +0100
> @@ -34,6 +34,20 @@
>  * The QA team's purpose is to provide cross-team assistance in keeping the
>    tree in a good state. This is done primarily by finding and pointing out
>    issues to maintainers and, where necessary, taking direct action.
> +* The QA team is directed by a lead, chosen yearly by private or
> +  public election among the members of the team. The QA team lead can
> +  choose one member as a deputy. The deputy has all of his powers directly
> +  delegated from the QA team lead and thus his actions and decisions should
> +  be considered equal to those of the QA team lead. The deputy is directly
> +  responsible only to the QA team lead.

Since QA is getting lots of powers these days, I strongly object to
this, see also my comment on becoming a QA member.  I suggest the
following:

The QA lead is yearly elected by the whole dev-community (active
developers), same procedure as being used for a council voting.  The
nomination is also done by developers, but they can only chose from the
current QA-members.

> +* The QA team lead must approve developers who would like to join the project. The
> +  applicant must demonstrate a thorough understanding of the duties he would like
> +  to perform. By accepting the applicant the QA team lead will accept
> +  the responsibility to direct them as part of the team and will be held
> +  responsible for any action the team member takes on behalf of the QA team.

Again, I strongly object to this plan.  Instead:

To become a QA member, one must be a current developer, for at least 6
months, and one must go through a quiz.  The quiz is then evaluated by
the QA lead or a replacing member from the QA team, in the same way as
recruiters evaluate new developers.  The outcome of the evaluation is
signed by the QA lead.  In case of decline of a new member after the
evalation, the QA lead must be able to provide a written argumentation
of this decline, which can be requested by said member or by devrel.  If
providing such argumentation is impossible within a week after
evaluation, QA must accept said member to the QA team.

> +* Any QA team lead decision can be revoked by a major opposing vote from
> +  all current QA members. Given the nature of this action new elections
> +  should be held within 1 month to elect a new QA team lead.
>  * In case of emergency, or if package maintainers refuse to cooperate,
>    the QA team may take action themselves to fix the problem.  The QA team
>    does not want to override the maintainer's wishes by default, but only
> @@ -50,7 +64,7 @@
>    an interim solution and it is expected that a bug will be opened with the
>    appropriate team to work towards a correct solution.
>  * In the case of disagreement among QA members the majority of established
> -  QA members must agree with the action.  Some examples of disagreements are:
> +  QA members must agree with the action. Some examples of disagreements are:

sentences are separated by double spaces, nevertheless, this doesn't
belong in this patch

>    whether the percieved problem violates the policy or whether the solution
>    makes the situation worse.
>  * In the event that a developer still insists that a package does not break
> @@ -59,17 +73,23 @@
>    made by the council.
>  * Just because a particular QA violation has yet to cause an issue does not
>    change the fact that it is still a QA violation.
> -* If a particular developer persistently causes breakage, the QA team
> -  may request that devrel re-evaluates that developer's commit rights.
> -  Evidence of past breakages will be presented with this request to devrel.
> +* In case a particular developer persistently causes breakage, the QA
> +  lead may request commit rights of given developer to be suspended by
> +  the Infra team. Devrel should then proceed to evaluate the situation, by
> +  finding a compromise or permanently revoking those rights.
> +* Should a situation arise where a developer causes breakage to the point
> +  that it cannot be ascribed to bona-fide mistake, either the QA lead or two
> +  members of the QA team can require the Infra team to temporarily suspend
> +  access to said developer, pending analysis of the causes and resolution
> +  to be provided by the QA team within 14 days of said suspension.
> +  Resolution for this kind of issue is completely in hands of the QA team
> +  and only the Gentoo Council can revisit the case.

It seems I feel the same as Rich here.  I object against this policy,
instead:

After QA suspension, resolution must go through devrel with QA lead as the
party that sets up the argumentation/evidence for said actions, and
suggested resolution.  However, devrel will evaluate and perform the
final statement/actions here.

>  * The QA team will maintain a list of current "QA Standards" with explanations
>    as to why they are problems, and how to fix the problem.  The list is not
>    meant by any means to be a comprehensive document, but rather a dynamic
>    document that will be updated as new problems are discovered.  The QA team
>    will also do their best to ensure all developer tools are in line with the
>    current QA standards.
> -* In order to join the QA team, you must be a developer for at least 4 months
> -  and must ask the current lead for approval.
>  * The QA team will work with Recruiters to keep related documentation and
>    quizzes up to date, so that up and coming developers will have access to all
>    of the necessary information to avoid past problems.


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-dev] Glep 48 update (as nominated for next meeting)

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 610 bytes --]

On 01/29/2011 12:42 AM, Rich Freeman wrote:

> 
> Finally, if Devrel, QA, and the Council have already talked this out
> and agree that QA is in the best place to police technical commit
> issues, then pipe this email to /dev/null...
> 

The diff proposed in this thread has not yet been talked about within
either Council or DevRel. The next council meeting should be at most
about talking about the diff and not making a decision as I wrote to the
council agenda thread on gentoo-project. I am rather busy this weekend
so I will have to get back to this thread next week.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-dev] Glep 48 update (as nominated for next meeting)

[Alec Warner]

On Sat, Jan 29, 2011 at 5:07 AM, Fabian Groffen <grobian@gentoo.org> wrote:
> On 28-01-2011 22:11:30 +0100, Tomáš Chvátal wrote:
>> So draft we would like to have implemented as Glep update is this diff:
>> http://dev.gentoo.org/~scarabeus/glep-0048.diff
>>
>> Please comment and help us improve the "english" of the whole document
>> so it gets accepted :)
>
> (:Nread http://dev.gentoo.org/~scarabeus/glep-0048.diff)
>> --- glep-0048.txt     2006-09-05 22:45:04.000000000 +0200
>> +++ glep-0048.new.txt 2011-01-25 13:49:38.525343000 +0100
>> @@ -34,6 +34,20 @@
>>  * The QA team's purpose is to provide cross-team assistance in keeping the
>>    tree in a good state. This is done primarily by finding and pointing out
>>    issues to maintainers and, where necessary, taking direct action.
>> +* The QA team is directed by a lead, chosen yearly by private or
>> +  public election among the members of the team. The QA team lead can
>> +  choose one member as a deputy. The deputy has all of his powers directly
>> +  delegated from the QA team lead and thus his actions and decisions should
>> +  be considered equal to those of the QA team lead. The deputy is directly
>> +  responsible only to the QA team lead.
>
> Since QA is getting lots of powers these days, I strongly object to
> this, see also my comment on becoming a QA member.  I suggest the
> following:
>
> The QA lead is yearly elected by the whole dev-community (active
> developers), same procedure as being used for a council voting.  The
> nomination is also done by developers, but they can only chose from the
> current QA-members.
>
>> +* The QA team lead must approve developers who would like to join the project. The
>> +  applicant must demonstrate a thorough understanding of the duties he would like
>> +  to perform. By accepting the applicant the QA team lead will accept
>> +  the responsibility to direct them as part of the team and will be held
>> +  responsible for any action the team member takes on behalf of the QA team.
>
> Again, I strongly object to this plan.  Instead:
>
> To become a QA member, one must be a current developer, for at least 6
> months, and one must go through a quiz.  The quiz is then evaluated by
> the QA lead or a replacing member from the QA team, in the same way as
> recruiters evaluate new developers.  The outcome of the evaluation is
> signed by the QA lead.  In case of decline of a new member after the
> evalation, the QA lead must be able to provide a written argumentation
> of this decline, which can be requested by said member or by devrel.  If
> providing such argumentation is impossible within a week after
> evaluation, QA must accept said member to the QA team.
>
>> +* Any QA team lead decision can be revoked by a major opposing vote from
>> +  all current QA members. Given the nature of this action new elections
>> +  should be held within 1 month to elect a new QA team lead.
>>  * In case of emergency, or if package maintainers refuse to cooperate,
>>    the QA team may take action themselves to fix the problem.  The QA team
>>    does not want to override the maintainer's wishes by default, but only
>> @@ -50,7 +64,7 @@
>>    an interim solution and it is expected that a bug will be opened with the
>>    appropriate team to work towards a correct solution.
>>  * In the case of disagreement among QA members the majority of established
>> -  QA members must agree with the action.  Some examples of disagreements are:
>> +  QA members must agree with the action. Some examples of disagreements are:
>
> sentences are separated by double spaces, nevertheless, this doesn't
> belong in this patch

This is currently up for debate on the internet ;)

http://desktoppub.about.com/cs/typespacing/a/onetwospaces.htm

>
>>    whether the percieved problem violates the policy or whether the solution
>>    makes the situation worse.
>>  * In the event that a developer still insists that a package does not break
>> @@ -59,17 +73,23 @@
>>    made by the council.
>>  * Just because a particular QA violation has yet to cause an issue does not
>>    change the fact that it is still a QA violation.
>> -* If a particular developer persistently causes breakage, the QA team
>> -  may request that devrel re-evaluates that developer's commit rights.
>> -  Evidence of past breakages will be presented with this request to devrel.
>> +* In case a particular developer persistently causes breakage, the QA
>> +  lead may request commit rights of given developer to be suspended by
>> +  the Infra team. Devrel should then proceed to evaluate the situation, by
>> +  finding a compromise or permanently revoking those rights.
>> +* Should a situation arise where a developer causes breakage to the point
>> +  that it cannot be ascribed to bona-fide mistake, either the QA lead or two
>> +  members of the QA team can require the Infra team to temporarily suspend
>> +  access to said developer, pending analysis of the causes and resolution
>> +  to be provided by the QA team within 14 days of said suspension.
>> +  Resolution for this kind of issue is completely in hands of the QA team
>> +  and only the Gentoo Council can revisit the case.
>
> It seems I feel the same as Rich here.  I object against this policy,
> instead:
>
> After QA suspension, resolution must go through devrel with QA lead as the
> party that sets up the argumentation/evidence for said actions, and
> suggested resolution.  However, devrel will evaluate and perform the
> final statement/actions here.
>
>>  * The QA team will maintain a list of current "QA Standards" with explanations
>>    as to why they are problems, and how to fix the problem.  The list is not
>>    meant by any means to be a comprehensive document, but rather a dynamic
>>    document that will be updated as new problems are discovered.  The QA team
>>    will also do their best to ensure all developer tools are in line with the
>>    current QA standards.
>> -* In order to join the QA team, you must be a developer for at least 4 months
>> -  and must ask the current lead for approval.
>>  * The QA team will work with Recruiters to keep related documentation and
>>    quizzes up to date, so that up and coming developers will have access to all
>>    of the necessary information to avoid past problems.
>
>
> --
> Fabian Groffen
> Gentoo on a different level
>
>

Re: [gentoo-dev] Glep 48 update (as nominated for next meeting)

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 683 bytes --]

On 1/28/11 10:11 PM, Tomáš Chvátal wrote:
> So draft we would like to have implemented as Glep update is this diff:
> http://dev.gentoo.org/~scarabeus/glep-0048.diff

I'd suggest to split the diff, discussion and voting to make it more
focused:

1) QA team lead, deputy, and accepting new members of the QA team
2) Revoking/reevaluating commit rights

While I mostly agree with both suggested updates, 2) is obviously very
controversial. It would be great to hear what QA team thinks about it,
especially some rationale about the changes.

Also, I think we don't have a "too much QA" problem in Gentoo. The
opposite may be true (i.e. "not enough QA").

Paweł


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: [gentoo-dev] Glep 48 update (as nominated for next meeting)

[Dane Smith]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/29/2011 08:07 AM, Fabian Groffen wrote:
> On 28-01-2011 22:11:30 +0100, Tomáš Chvátal wrote:
>> So draft we would like to have implemented as Glep update is this diff:
>> http://dev.gentoo.org/~scarabeus/glep-0048.diff
>>
>> Please comment and help us improve the "english" of the whole document
>> so it gets accepted :)
> 
> (:Nread http://dev.gentoo.org/~scarabeus/glep-0048.diff)
>> --- glep-0048.txt	2006-09-05 22:45:04.000000000 +0200
>> +++ glep-0048.new.txt	2011-01-25 13:49:38.525343000 +0100
>> @@ -34,6 +34,20 @@
>>  * The QA team's purpose is to provide cross-team assistance in keeping the
>>    tree in a good state. This is done primarily by finding and pointing out
>>    issues to maintainers and, where necessary, taking direct action.
>> +* The QA team is directed by a lead, chosen yearly by private or
>> +  public election among the members of the team. The QA team lead can
>> +  choose one member as a deputy. The deputy has all of his powers directly
>> +  delegated from the QA team lead and thus his actions and decisions should
>> +  be considered equal to those of the QA team lead. The deputy is directly
>> +  responsible only to the QA team lead.
> 
> Since QA is getting lots of powers these days, I strongly object to
> this, see also my comment on becoming a QA member.  I suggest the
> following:
> 
> The QA lead is yearly elected by the whole dev-community (active
> developers), same procedure as being used for a council voting.  The
> nomination is also done by developers, but they can only chose from the
> current QA-members.
> 
>> +* The QA team lead must approve developers who would like to join the project. The
>> +  applicant must demonstrate a thorough understanding of the duties he would like
>> +  to perform. By accepting the applicant the QA team lead will accept
>> +  the responsibility to direct them as part of the team and will be held
>> +  responsible for any action the team member takes on behalf of the QA team.
> 
> Again, I strongly object to this plan.  Instead:
> 
> To become a QA member, one must be a current developer, for at least 6
> months, and one must go through a quiz.  The quiz is then evaluated by
> the QA lead or a replacing member from the QA team, in the same way as
> recruiters evaluate new developers.  The outcome of the evaluation is
> signed by the QA lead.  In case of decline of a new member after the
> evalation, the QA lead must be able to provide a written argumentation
> of this decline, which can be requested by said member or by devrel.  If
> providing such argumentation is impossible within a week after
> evaluation, QA must accept said member to the QA team.
> 

I whole-heartedly disagree with this. First off, the "line in the sand"
concept is completely unnecessary in this case. It barely makes sense
when it's used on a massive scale (can't drink until 21 in the US), and
it only makes sense there because people could not feasibly be evaluated
on an individual basis. In this case, quite clearly they can. Either
they have the skills and the motivation, or they don't. Some x month
line in the sand makes no difference at all and merely slows people down
who would like to help and contribute. We have enough hurdles around
here. Why add more?

The same can be said for the quiz. If the current QA lead would like to
decide that way, it should be up to him. But on the whole it should be
the QA leads decision. Personally I think the idea is kind of crazy, and
seems like a waste of time. Evaluation can be done quite easily on a
case by case basis. Why bother with quizzes?

>> +* Any QA team lead decision can be revoked by a major opposing vote from
>> +  all current QA members. Given the nature of this action new elections
>> +  should be held within 1 month to elect a new QA team lead.
>>  * In case of emergency, or if package maintainers refuse to cooperate,
>>    the QA team may take action themselves to fix the problem.  The QA team
>>    does not want to override the maintainer's wishes by default, but only
>> @@ -50,7 +64,7 @@
>>    an interim solution and it is expected that a bug will be opened with the
>>    appropriate team to work towards a correct solution.
>>  * In the case of disagreement among QA members the majority of established
>> -  QA members must agree with the action.  Some examples of disagreements are:
>> +  QA members must agree with the action. Some examples of disagreements are:
> 
> sentences are separated by double spaces, nevertheless, this doesn't
> belong in this patch
> 
>>    whether the percieved problem violates the policy or whether the solution
>>    makes the situation worse.
>>  * In the event that a developer still insists that a package does not break
>> @@ -59,17 +73,23 @@
>>    made by the council.
>>  * Just because a particular QA violation has yet to cause an issue does not
>>    change the fact that it is still a QA violation.
>> -* If a particular developer persistently causes breakage, the QA team
>> -  may request that devrel re-evaluates that developer's commit rights.
>> -  Evidence of past breakages will be presented with this request to devrel.
>> +* In case a particular developer persistently causes breakage, the QA
>> +  lead may request commit rights of given developer to be suspended by
>> +  the Infra team. Devrel should then proceed to evaluate the situation, by
>> +  finding a compromise or permanently revoking those rights.
>> +* Should a situation arise where a developer causes breakage to the point
>> +  that it cannot be ascribed to bona-fide mistake, either the QA lead or two
>> +  members of the QA team can require the Infra team to temporarily suspend
>> +  access to said developer, pending analysis of the causes and resolution
>> +  to be provided by the QA team within 14 days of said suspension.
>> +  Resolution for this kind of issue is completely in hands of the QA team
>> +  and only the Gentoo Council can revisit the case.
> 
> It seems I feel the same as Rich here.  I object against this policy,
> instead:
> 
> After QA suspension, resolution must go through devrel with QA lead as the
> party that sets up the argumentation/evidence for said actions, and
> suggested resolution.  However, devrel will evaluate and perform the
> final statement/actions here.
> 
>>  * The QA team will maintain a list of current "QA Standards" with explanations
>>    as to why they are problems, and how to fix the problem.  The list is not
>>    meant by any means to be a comprehensive document, but rather a dynamic
>>    document that will be updated as new problems are discovered.  The QA team
>>    will also do their best to ensure all developer tools are in line with the
>>    current QA standards.
>> -* In order to join the QA team, you must be a developer for at least 4 months
>> -  and must ask the current lead for approval.
>>  * The QA team will work with Recruiters to keep related documentation and
>>    quizzes up to date, so that up and coming developers will have access to all
>>    of the necessary information to avoid past problems.
> 
> 

I also 100% agree with Paweł. This diff should probably be separated
into 2 different diffs. One with the general structure, one with the
very controversial bit.

Personally, I think the debate on the teams day to day magic is more or
less unnecessary. Every team gets to make decisions on its day to day
management without having to jump through hoops (provided they are still
in line with the teams mission/purpose). I do not feel it is necessary
to add more bureaucracy than is 100% necessary into any teams day to day
activities. As long as a team is in line with its mission and isn't
causing any problems, they should be left alone. If they begin to cause
issues, then it is time for discussion.


Regards,
- -- 
Dane Smith (c1pher)
Gentoo Linux Developer -- Crypto / Sunrise / x86
RSA Key: http://pgp.mit.edu:11371/pks/lookup?search=0x0C2E1531&op=index
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNRhe4AAoJEEsurZwMLhUxhEEQAL/DoHNnGkouR1NAd/FQndcs
/DlPGnyZIoD/62qCw7C/3+eDIaqwjgGNGB3lArSLiOheUINu5Jm2P7zlX6cdiPr5
M6M8wGsLJDhyvnN4EL+b+REqSUYbhW61e5uEt3IPRcaibtp4YwbBb2PdDKkl9fDH
/j2GgqkXUWdVGjOZp/vgpkiyFg9HJm1XrEy/rkRAaPdJlV5rJuqZH9h1TNmY8oeh
eiC7oaNiFBY/ibuGNYD9lklyP72ooN2gCESXiQuq/+1e13b+DwqOl1nZmABKIIWH
tSptWdP5ikhlITLqjsaHJyqeL37EH/R4Jsf/sms2qhGWOh2hi7xUznlOcXFetN9B
CJF8E/FWtmDmJkwBnkGsE++ASokbxB9w0m0krmjhXKuHZRzO2VrnjYpr4LiJOFd2
j+vCygpqnMrktC7sDAabKkuuJzZuinQ5dRZnQ6NLnTQ3UB4rMbqeC1djwC0hkSJV
uh4+idnZywj1D71OW4r6kw2gRUBS04C/KfNJgKx65dTEF5oYsQaJihh7Vad7YBQE
EPvugUaLui5qtX1+tvbIMIJUN+018uaa9idakAfjLxAJb1tqjvRMPTGoS1D/NLDM
S7kaXzJTIKhDA6OI/ugtyTHSs/IizTjdIWn58RlZbiMvSZki7x2xbRUDB0Fegwk9
Z2q3xp2RmGLxI8iel+r0
=8SID
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Glep 48 update (as nominated for next meeting)

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 849 bytes --]

On 22:11 Fri 28 Jan     , Tomáš Chvátal wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> first off i would like to apologize for not sending this mail sooner
> (helluva week).
> 
> So draft we would like to have implemented as Glep update is this diff:
> http://dev.gentoo.org/~scarabeus/glep-0048.diff
> 
> Please comment and help us improve the "english" of the whole document
> so it gets accepted :)

I think the question of whether a lead's decision can be revoked by a 
majority vote of the team should be a global Gentoo policy and not 
team-specific. I personally disagree that it should be possible, but 
that is a separate decision from whether it should be a common process 
across all of Gentoo.

-- 
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Glep 48 update (as nominated for next meeting)

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 1246 bytes --]

On 14:07 Sat 29 Jan     , Fabian Groffen wrote:
> Since QA is getting lots of powers these days, I strongly object to 
> this, see also my comment on becoming a QA member.  I suggest the 
> following:
> 
> The QA lead is yearly elected by the whole dev-community (active 
> developers), same procedure as being used for a council voting.  The 
> nomination is also done by developers, but they can only chose from 
> the current QA-members.

I already think there's too much time wasted on bureaucratic stuff that 
distracts us from actually getting work done. We're here to create an 
awesome source-based distribution, not pretend we're United Nations and 
the U.S. government all rolled into one. =)

In my opinion, reaching the minimum number of elections that allows 
Gentoo to remain functional should be the goal. There's nothing wrong 
with concentrating power in a smaller number of people using a 
meritocratic process -- OSS communities seem to operate much better as a 
meritocracy than a democracy, as that provides an incentive to actually 
get stuff done instead of talk about the best process for it all day.

-- 
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Glep 48 update (as nominated for next meeting)

[Jeroen Roovers]

On Sun, 30 Jan 2011 21:00:24 -0500
Dane Smith <c1pher@gentoo.org> wrote:

> I whole-heartedly disagree with this. First off, the "line in the
> sand" concept is completely unnecessary in this case. It barely makes
> sense when it's used on a massive scale (can't drink until 21 in the
> US), and it only makes sense there because people could not feasibly
> be evaluated on an individual basis. In this case, quite clearly they
> can. Either they have the skills and the motivation, or they don't.
> Some x month line in the sand makes no difference at all and merely
> slows people down who would like to help and contribute. We have
> enough hurdles around here. Why add more?

Because these half year olds would despite their limited experience
gain direct access to the big red stop button on the pole in the sand
that's coupled to someone else's commit privileges. I think six months
isn't nearly enough.

> The same can be said for the quiz. If the current QA lead would like
> to decide that way, it should be up to him. But on the whole it
> should be the QA leads decision. Personally I think the idea is kind
> of crazy, and seems like a waste of time. Evaluation can be done
> quite easily on a case by case basis. Why bother with quizzes?

As above.

Having inexperienced developers who are apparently very eager to start
"enforcing" QA through devrel - that's rather scary too.


     jer

Re: [gentoo-dev] Glep 48 update (as nominated for next meeting)

[Jeroen Roovers]

On Sun, 30 Jan 2011 20:39:15 -0600
Donnie Berkholz <dberkholz@gentoo.org> wrote:

> We're here to create an awesome source-based distribution, not
> pretend we're United Nations and the U.S. government all rolled into
> one. =)

I've been observing for a few years now how sometimes a developer leans
toward a more corporate style over time.

We're an open source project, most of us are volunteers, and normal
corporate policy doesn't hold here, and yet now and again I see
proposals to technically or socially improve the project in a way that
comes down to three actions:

1) invest - money, time and/or other means; and/or

2) regroup; and/or

3) grant privileges for a special subset of people to act upon another
   subset of people.


= 1. The Leg Up =

Of course, investing means you have, well, the means to invest. Money
and goods usually aren't the means to invest in a project like ours,
but many requests seem to say that a particular ailment will
magically disappear after we throw another five person-weeks at it. We
do not have these resources, and we have no accounting for them, and we
do not set strict targets that way, so that's the entire corporate
model out the window for us. Scarcity of resources is exactly what makes
an open source project progress - you leave all the problematic bits
open to see, and some hapless user will ultimately come along and fix
it for you, or you finally find the time to do it yourself, or you
talk enthusiastically about it to someone else and she does it for you.


= 2. The Escalator =

Arranging developers in new hierarchies is not going to fix any
problems. In a corporate environment, you can simply cut out some
middlemen, put some new coordinators in place to oversee some team or
teams, and generally fire a dozen here and hire a dozen there as
needed, and nobody hurts (for very long) as it's usually all a big
shuffle among the same population of workers.

It's a good thing to have an escalator for conflicts (of interest or of
a technical nature), and we've luckily had that for years. Sometimes
the escalator needs fixing, but every time you fix it, some people are
going to walk away, some others will retreat into the safety of toiling
in some badly lit backroom where nobody bothers them, and a few will
simply decide that publicly discussing new ideas will just get them cut
down by their peers again. Regrouping is a kind of investing, and since
you can't even tell people what to do, it's not very wise to start
arguing to change the hierarchy - it's probably a better idea to set up
a new project, outline what needs to be done, and try to simply attract
the person-hours you need until the project has achieved its goal.


= 3. The Elevator =

Rearranging power in the sense of giving special privileges to
particular people (a direct line to the president, personal notification
when our team scores, an order to go out and buy some new socks, size
12, the ability to quickly decide when someone else's privileges
should be revoked) is another very good way to not treat volunteers. It
works very well in a corporate setting, because you can fire people or
even sue for damages when they abuse their privileges, so most works
wouldn't abuse them just like that or at least make sure their use of
the privileges is somehow accountable. Similarly instilling fear in
volunteers has the opposite effect.


The ideas that do come through in volunteer projects usually excel in
simplicity. They use the same or fewer resources than the conflict they
intend to end. And nobody ends up with better privileges than others,
or executive powers greater than those of their peers. You just see more
people volunteering more work.


     jer

Re: [gentoo-dev] Glep 48 update (as nominated for next meeting)

[Jeroen Roovers]

On Fri, 28 Jan 2011 17:42:19 -0500
Rich Freeman <rich0@gentoo.org> wrote:

> 1.  It makes sense that in the event that a "Rogue" developer is
> wreaking havoc on the tree that QA can get infra to suspend their
> commit rights.  That's safeguarding the tree in the face of imminent
> harm.  This should generally be limited to serious issues (people
> running scripts to mass-update packages, bad changes to system
> packages, etc), and not because there is some dispute over whether
> some obscure package should or should-not be masked.

No, it makes no sense at all. /Anyone/ can ask infra to do that, users
as well as developers, and infra will then probably want to see some
details of commits or other evidence to support the suspension.

You simply file a bug report, make sure devrel and infra know about it,
and just make a lot of noise until stuff gets fixed - if it's all that
bad. We've never needed QA to do it for us before, have we?

> 2.  I don't think it makes sense for QA to discipline developers
> permanently in these cases.  They should suspend access pending Devrel
> resolution of the issue.  Devrel should of course strongly consider
> the input of QA.

That should be anyone's input, really. If a Gentoo Linux user finds a
nasty `rm -rf /' timebomb, I suppose he could point that out to infra
directly. And it's infra that suspends access, by the way. And devrel
should be the intermediate between developers. And QA "aims to keep the
portage tree in a consistent state"[1]. Wait, everyone is already in
place?

What makes QA so special? If we grant them this new power, then that is
what makes them special, I guess.


     jer


[1] http://www.gentoo.org/proj/en/qa/

Re: [gentoo-dev] Glep 48 update (as nominated for next meeting)

[Fabian Groffen]

On 30-01-2011 21:00:24 -0500, Dane Smith wrote:
> > Again, I strongly object to this plan.  Instead:
> > 
> > To become a QA member, one must be a current developer, for at least 6
> > months, and one must go through a quiz.  The quiz is then evaluated by
> > the QA lead or a replacing member from the QA team, in the same way as
> > recruiters evaluate new developers.  The outcome of the evaluation is
> > signed by the QA lead.  In case of decline of a new member after the
> > evalation, the QA lead must be able to provide a written argumentation
> > of this decline, which can be requested by said member or by devrel.  If
> > providing such argumentation is impossible within a week after
> > evaluation, QA must accept said member to the QA team.
> 
> I whole-heartedly disagree with this. First off, the "line in the sand"
> concept is completely unnecessary in this case. It barely makes sense
> when it's used on a massive scale (can't drink until 21 in the US), and
> it only makes sense there because people could not feasibly be evaluated
> on an individual basis. In this case, quite clearly they can. Either
> they have the skills and the motivation, or they don't. Some x month
> line in the sand makes no difference at all and merely slows people down
> who would like to help and contribute. We have enough hurdles around
> here. Why add more?

Because some members show different behaviour than before/during
recruiting.

> The same can be said for the quiz. If the current QA lead would like to
> decide that way, it should be up to him. But on the whole it should be
> the QA leads decision. Personally I think the idea is kind of crazy, and
> seems like a waste of time. Evaluation can be done quite easily on a
> case by case basis. Why bother with quizzes?

I guess you also prefer the council members chosing their own
replacements then, do you?
If QA were just a normal team like most others, I couldn't care less
about how they are chosen and who is their lead.


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-dev] Glep 48 update (as nominated for next meeting)

[Fabian Groffen]

On 30-01-2011 20:31:24 -0600, Donnie Berkholz wrote:
> On 22:11 Fri 28 Jan     , Tomáš Chvátal wrote:
> > So draft we would like to have implemented as Glep update is this diff:
> > http://dev.gentoo.org/~scarabeus/glep-0048.diff
> > 
> > Please comment and help us improve the "english" of the whole document
> > so it gets accepted :)
> 
> I think the question of whether a lead's decision can be revoked by a 
> majority vote of the team should be a global Gentoo policy and not 
> team-specific. I personally disagree that it should be possible, but 
> that is a separate decision from whether it should be a common process 
> across all of Gentoo.

I already think there's too much time wasted on bureaucratic stuff that
distracts us from actually getting work done.


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-dev] Glep 48 update (as nominated for next meeting)

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 816 bytes --]

On 01/31/2011 07:04 AM, Jeroen Roovers wrote:
> 
>> 2.  I don't think it makes sense for QA to discipline developers
>> permanently in these cases.  They should suspend access pending Devrel
>> resolution of the issue.  Devrel should of course strongly consider
>> the input of QA.
> 
> That should be anyone's input, really. If a Gentoo Linux user finds a
> nasty `rm -rf /' timebomb, I suppose he could point that out to infra
> directly. And it's infra that suspends access, by the way. And devrel
> should be the intermediate between developers. And QA "aims to keep the
> portage tree in a consistent state"[1]. Wait, everyone is already in
> place?
> 

Actually recruiters can also suspend commit access and DevRel lead has
used that to safe guard the tree in the past.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-dev] Glep 48 update (as nominated for next meeting)

[Alec Warner]

I'm going to basically reply with my normal QA rant.

1) QA is important to the overall health of Gentoo.  People will not
use broken shit.
2) QA should be straightforward.  If a developer need to do X to
assure quality it should be fairly obvious why X is required.  It
should be clear where to go for help.
  2a) A developer should not get chewed out for asking for assistance
or questioning policies.
3) If a QA policy is not straightforward; developers will not follow it.
4) QA should not be a road-block to most developers.  If you make
development harder people will often stop working on development.

I think a number of developers understand why QA exists, why they
should test packages, run repoman, and other policies that often get
followed.  Examining policies that are ignored will likely lead to a
lack of understanding, documentation, or just bloat in policy.

In general I hate talking about 'bad' QA versus 'good' QA because no
one on the QA team ever talked about measurement.  QA is 'bad' when
some new person heads up the team and (s)he is going to 'clean up QA'
by instituting these new policies.  None of the policies have any kind
of measurement attached so there is no real way to see if the new
policies are effective.  Perhaps this sort of thing is 'too corporate'
and not possible in a volunteer project (I happen to think otherwise.)

-A

On Mon, Jan 31, 2011 at 12:14 AM, Petteri Räty <betelgeuse@gentoo.org> wrote:
> On 01/31/2011 07:04 AM, Jeroen Roovers wrote:
>>
>>> 2.  I don't think it makes sense for QA to discipline developers
>>> permanently in these cases.  They should suspend access pending Devrel
>>> resolution of the issue.  Devrel should of course strongly consider
>>> the input of QA.
>>
>> That should be anyone's input, really. If a Gentoo Linux user finds a
>> nasty `rm -rf /' timebomb, I suppose he could point that out to infra
>> directly. And it's infra that suspends access, by the way. And devrel
>> should be the intermediate between developers. And QA "aims to keep the
>> portage tree in a consistent state"[1]. Wait, everyone is already in
>> place?
>>
>
> Actually recruiters can also suspend commit access and DevRel lead has
> used that to safe guard the tree in the past.
>
> Regards,
> Petteri
>
>

Re: [gentoo-dev] Glep 48 update (as nominated for next meeting)

[Markos Chandras]

[-- Attachment #1: Type: text/plain, Size: 955 bytes --]

After thinking about this, I think it is ok for QA team to revoke
privileges for a specific developer. However, devrel must be
responsible for making this decision permanent or give the developer
another chance or whatever. As many of you have already said, it is
devreal who deals with humans not QA.

The x,y,z months+quiz solution seems an overkill to me. The lead must be able
to evaluate and say whether someone is good enough for QA or not. 
Having people doing more and more quizzes is not that smart. 
However, it might be nice if we assign one mentor (member of QA team) to
each of the new QA members and have the mentor taking care of his 
apprentice for like a month or so. QA team is far too understaffed 
(like everything else in Gentoo) so we should focus more on how to bring 
more people in QA team and train them within under real circumstances.

Regards,
-- 
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Glep 48 update (as nominated for next meeting)

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 1103 bytes --]

On 09:06 Mon 31 Jan     , Fabian Groffen wrote:
> On 30-01-2011 20:31:24 -0600, Donnie Berkholz wrote:
> > On 22:11 Fri 28 Jan     , Tomáš Chvátal wrote:
> > > So draft we would like to have implemented as Glep update is this diff:
> > > http://dev.gentoo.org/~scarabeus/glep-0048.diff
> > > 
> > > Please comment and help us improve the "english" of the whole document
> > > so it gets accepted :)
> > 
> > I think the question of whether a lead's decision can be revoked by a 
> > majority vote of the team should be a global Gentoo policy and not 
> > team-specific. I personally disagree that it should be possible, but 
> > that is a separate decision from whether it should be a common process 
> > across all of Gentoo.
> 
> I already think there's too much time wasted on bureaucratic stuff that
> distracts us from actually getting work done.

<grins>

I agree with not having a bunch of rules. But I think that when they do 
exist, they should at least be consistent.

-- 
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]