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
Il giorno dom, 23/01/2011 alle 10.00 +0100, Torsten Veller ha scritto:
> 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
> a team IMHO.
I'd be all for not having to specify so much the presence of the QA
lead, but the problem lies in what the past year taught us: devrel will
refuse to cooperate to anybody on the QA team but the lead.
With "cooperate" here I don't only mean "listen to the requests for
suspension"; devrel refused to keep the team as a whole in the loop of
pending requests, as well as ignoring any evidence/suggestion coming
from single team members.
Which is why they "force" us to actually specify a lead in our very
> "the lead will be held responsible for their actions"
> I think this can be dropped: the team is responsible for its actions
> (whatever that means) and the lead will be replaced soon too.
It's a matter of bringing some balance in the game; if we drop the four
months rule, one could expect that the lead could call in his cronies
just to take over QA. By forcing a lead to take direct responsibility
for the people he or she let join the team.
Maybe I should specify it better, but it was intended as implicitly not
making the lead be directly responsible for the members that were on the
> "be ascribed to bona-fide mistake" --
> how can we evaluate this?
> Do you think this rule would have been used in the past?
This would be easy to pass under the "it's just common sense" idea, but
I wanted to have it in anyway. If a developer ends up breaking the tree
by simply not thinking about the effects of his or her action, that's
bad, but it's one thing.
When a developer knows very well what his or her actions imply but still
applies them without caring about the repercussions, that cannot be
ascribed to bona-fide.
As an example, think about a developer committing a non-masked package,
the installation of which prevents Portage from completing its tasks
correctly. By default it's just a mistake, but if said developer
actually provided the fix beforehand to the Portage team but then didn't
wait for it to be deployed before committing the package, then it cannot
be a mistake in good faith.
Diego Elio Pettenò — Flameeyes
signature.asc (This is a digitally signed message part)