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@g.o> 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
>
>