From: "Diego Elio Pettenò" <flameeyes@gmail.com>
To: gentoo-qa@lists.gentoo.org
Subject: Re: [gentoo-qa] Re: Proposed changes to GLEP48
Date: Sun, 23 Jan 2011 11:52:44 +0100 [thread overview]
Message-ID: <1295779964.2648.117.camel@raven.home.flameeyes.eu> (raw)
In-Reply-To: <20110123084830.TAb245b0.tv@veller.net>
[-- Attachment #1: Type: text/plain, Size: 2416 bytes --]
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/
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
next prev parent reply other threads:[~2011-01-23 11:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-22 21:07 [gentoo-qa] Proposed changes to GLEP48 Diego Elio Pettenò
2011-01-22 22:11 ` Markos Chandras
2011-01-22 22:17 ` Luca Barbato
2011-01-23 9:00 ` [gentoo-qa] " Torsten Veller
2011-01-23 10:52 ` Diego Elio Pettenò [this message]
2011-01-23 12:01 ` [gentoo-qa] " Tomáš Chvátal
2011-01-24 20:59 ` Tomáš Chvátal
2011-01-25 12:45 ` Markos Chandras
2011-01-25 14:39 ` Peter Volkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1295779964.2648.117.camel@raven.home.flameeyes.eu \
--to=flameeyes@gmail.com \
--cc=gentoo-qa@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox