List Archive: gentoo-qa
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
* Diego Elio Pettenò <flameeyes@...>:
The current "QA team's role and purpose" (GLEP 48) always talks about
the QA TEAM -- and I think this is good: QA needs a leader who can build
a team IMHO.
(Only once the lead is mentioned: New team members have to be approved
by the lead.)
> +* 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 deputy, whose decisions should be considered as
> + they were made by the lead in case he (or she) is not available.
"[Projects] may have one or many leads, and the leads are selected by
the members of the project. This selection must occur at least once
every 12 months, and may occur at any time." [GLEP 39]
Why did you drop the "any time" rule?
"not available" -- within two hours, two days or two weeks, or devaway
or until the end of the fixed one-year-term (instead of running a new
election)? Or: How can the other teams know that the deputy takes the
> +* The QA team lead approves applicant developers as team members. By
> + doing this he (or she) will accept to direct them as part of the team
> + and will be held responsible for their actions, as taken on behalf
> + of the QA team.
Here you wanted to drop the developer-for-four-months requirement. Ok.
"the lead will be held responsible for their actions"
I think this can be dropped: the team is responsible for its actions anyway
(whatever that means) and the lead will be replaced soon too.
> -* 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 his (or her) commit rights to be suspended. Devrel
> + should then proceed to evalute the situation, by finding a
> + compromise or definitely revoking those rights.
What do you mean by "Devrel should then proceed to evalute the
situation, by finding a compromise or definitely revoking those
- QA specifies how Devrel is supposed to work in this case?
- Compromise between the particular developer and QA?
So if the QA team doesn't want to find a compromise, the developer
will have his commit bit definitely revoked?
> +* Should a situation arise where a developer causes breakage to the
> + point it cannot be ascribed to bona-fide mistake, either the lead or
"be ascribed to bona-fide mistake" --
how can we evaluate this?
Do you think this rule would have been used in the past?
> + 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 within a week of said suspension.
And then? Appeal to the council? Will unjustified decisions by the QA
team lead or the two members be investigated too?