Gentoo Archives: gentoo-qa

From: "Diego Elio Pettenò" <flameeyes@×××××.com>
To: gentoo-qa@l.g.o
Subject: Re: [gentoo-qa] Re: Proposed changes to GLEP48
Date: Sun, 23 Jan 2011 11:04:45
Message-Id: 1295779964.2648.117.camel@raven.home.flameeyes.eu
In Reply to: [gentoo-qa] Re: Proposed changes to GLEP48 by Torsten Veller
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 > build > 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 definition.
> "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.
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 team _before_.
> "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 http://blog.flameeyes.eu/

Attachments

File name MIME type
signature.asc application/pgp-signature