From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org)
by finch.gentoo.org with esmtp (Exim 4.60)
(envelope-from <gentoo-qa+bounces-144-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1PgxkK-0003bn-9f
for garchives@archives.gentoo.org; Sun, 23 Jan 2011 11:04:45 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 232AEE0A9F
for <garchives@archives.gentoo.org>; Sun, 23 Jan 2011 11:04:34 +0000 (UTC)
Received: from mail-ww0-f53.google.com (mail-ww0-f53.google.com [74.125.82.53])
by pigeon.gentoo.org (Postfix) with ESMTP id 17363E032F
for <gentoo-qa@lists.gentoo.org>; Sun, 23 Jan 2011 10:52:42 +0000 (UTC)
Received: by wwi18 with SMTP id 18so3136201wwi.10
for <gentoo-qa@lists.gentoo.org>; Sun, 23 Jan 2011 02:52:42 -0800 (PST)
Received: by 10.216.35.74 with SMTP id t52mr2357293wea.103.1295779961334;
Sun, 23 Jan 2011 02:52:41 -0800 (PST)
Received: from [172.28.64.145] (host249-252-static.95-94-b.business.telecomitalia.it [94.95.252.249])
by mx.google.com with ESMTPS id o19sm5932384wee.2.2011.01.23.02.52.38
(version=SSLv3 cipher=RC4-MD5);
Sun, 23 Jan 2011 02:52:40 -0800 (PST)
Sender: =?UTF-8?Q?Diego_Elio_Petten=C3=B2?= <flameeyes@hosting.flameeyes.eu>
Subject: Re: [gentoo-qa] Re: Proposed changes to GLEP48
From: Diego Elio =?ISO-8859-1?Q?Petten=F2?= <flameeyes@gmail.com>
To: gentoo-qa@lists.gentoo.org
In-Reply-To: <20110123084830.TAb245b0.tv@veller.net>
References: <1295730438.2648.99.camel@raven.home.flameeyes.eu>
<20110123084830.TAb245b0.tv@veller.net>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-8zqiJrzNEVK4BeMNd4Y4"
Date: Sun, 23 Jan 2011 11:52:44 +0100
Message-ID: <1295779964.2648.117.camel@raven.home.flameeyes.eu>
Precedence: bulk
List-Post: <mailto:gentoo-qa@lists.gentoo.org>
List-Help: <mailto:gentoo-qa+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-qa+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-qa+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-qa.gentoo.org>
X-BeenThere: gentoo-qa@lists.gentoo.org
Reply-to: gentoo-qa@lists.gentoo.org
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
X-Archives-Salt:
X-Archives-Hash: 05b0f140a023781b20904ef79836652f
--=-8zqiJrzNEVK4BeMNd4Y4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Il giorno dom, 23/01/2011 alle 10.00 +0100, Torsten Veller ha scritto:
>=20
> 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.=20
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?
>=20
> 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.
--=20
Diego Elio Petten=C3=B2 =E2=80=94 Flameeyes
http://blog.flameeyes.eu/
--=-8zqiJrzNEVK4BeMNd4Y4
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
iQEcBAABCAAGBQJNPAh5AAoJEBqCrVe7WSRDWoYH+gNpltMANr+JZvszu+9oDmPB
5UaEVRANxz67OU5kk1MhofiVqqvSQBdrSji2G5zpnKQ7UjKkLepSCZmIeRbgDg5p
WGdQVrz3deqTnRYz+4WU2ZPfbrrSZ/qCmy7fDVVBdMXOMVJydfI0fnQVqC4Rvz5d
Sm5M13iFd9ajqH42rtVIYdeA8P8MXO4i7oTqvrykcnibYBzeXCjkFxVJdJHpxw6d
L24UBzWYD+XaDoqfT4H/H9qjZ3recq0yOPq88tS6loAbEdrcNRofTf6/I1Ut8Q9j
GDuR7XcE9oEuvhcNVGeLvDRzRqyUp02yE8Cow0/evP/nQu5ljuO7U5Il+SNCNSo=
=e7cE
-----END PGP SIGNATURE-----
--=-8zqiJrzNEVK4BeMNd4Y4--