FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 01-28-2011, 11:05 PM
Roy Bamford
 
Default Glep 48 update (as nominated for next meeting)

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
 
Old 01-29-2011, 04:20 AM
Jeroen Roovers
 
Default Glep 48 update (as nominated for next meeting)

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
 
Old 01-29-2011, 10:53 AM
Roy Bamford
 
Default Glep 48 update (as nominated for next meeting)

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
 
Old 01-29-2011, 12:07 PM
Fabian Groffen
 
Default Glep 48 update (as nominated for next meeting)

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
 
Old 01-29-2011, 03:18 PM
Petteri Rty
 
Default Glep 48 update (as nominated for next meeting)

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
 
Old 01-29-2011, 11:26 PM
Alec Warner
 
Default Glep 48 update (as nominated for next meeting)

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
>
>
 
Old 01-30-2011, 05:08 PM
"Paweł Hajdan, Jr."
 
Default Glep 48 update (as nominated for next meeting)

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ł
 
Old 01-31-2011, 01:00 AM
Dane Smith
 
Default Glep 48 update (as nominated for next meeting)

-----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+REqSUYbhW61e5uEt3IPRcaibtp4Yw bBb2PdDKkl9fDH
/j2GgqkXUWdVGjOZp/vgpkiyFg9HJm1XrEy/rkRAaPdJlV5rJuqZH9h1TNmY8oeh
eiC7oaNiFBY/ibuGNYD9lklyP72ooN2gCESXiQuq/+1e13b+DwqOl1nZmABKIIWH
tSptWdP5ikhlITLqjsaHJyqeL37EH/R4Jsf/sms2qhGWOh2hi7xUznlOcXFetN9B
CJF8E/FWtmDmJkwBnkGsE++ASokbxB9w0m0krmjhXKuHZRzO2VrnjYpr 4LiJOFd2
j+vCygpqnMrktC7sDAabKkuuJzZuinQ5dRZnQ6NLnTQ3UB4rMb qeC1djwC0hkSJV
uh4+idnZywj1D71OW4r6kw2gRUBS04C/KfNJgKx65dTEF5oYsQaJihh7Vad7YBQE
EPvugUaLui5qtX1+tvbIMIJUN+018uaa9idakAfjLxAJb1tqjv RMPTGoS1D/NLDM
S7kaXzJTIKhDA6OI/ugtyTHSs/IizTjdIWn58RlZbiMvSZki7x2xbRUDB0Fegwk9
Z2q3xp2RmGLxI8iel+r0
=8SID
-----END PGP SIGNATURE-----
 
Old 01-31-2011, 01:31 AM
Donnie Berkholz
 
Default Glep 48 update (as nominated for next meeting)

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
 
Old 01-31-2011, 01:39 AM
Donnie Berkholz
 
Default Glep 48 update (as nominated for next meeting)

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
 

Thread Tools




All times are GMT. The time now is 07:12 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org