From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org)
	by nuthatch.gentoo.org with esmtp (Exim 4.54)
	id 1FDV6M-00053u-08
	for garchives@archives.gentoo.org; Sun, 26 Feb 2006 23:14:54 +0000
Received: from robin.gentoo.org (localhost [127.0.0.1])
	by robin.gentoo.org (8.13.5/8.13.5) with SMTP id k1QNDf7u007814;
	Sun, 26 Feb 2006 23:13:41 GMT
Received: from getafix.willow.local (169.248.adsl.brightview.com [80.189.248.169] (may be forged))
	by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id k1QNBSfH009998
	for <gentoo-dev@lists.gentoo.org>; Sun, 26 Feb 2006 23:11:28 GMT
Received: from dogmatix.willow.local ([192.168.0.100] helo=dogmatix)
	by getafix.willow.local with smtp (Exim 4.54)
	id 1FDV2v-0003wE-US
	for gentoo-dev@lists.gentoo.org; Sun, 26 Feb 2006 23:11:28 +0000
Received: by dogmatix (sSMTP sendmail emulation); Sun, 26 Feb 2006 23:11:21 +0000
From: johnm@gentoo.org
Date: Sun, 26 Feb 2006 23:11:21 +0000
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [RFC] QA Team's role
Message-ID: <20060226231121.GB11930@dogmatix.willow.local>
References: <20060226222217.GB17257@aerie.halcy0n.com>
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="adJ1OR3c6QgCpb/j"
Content-Disposition: inline
In-Reply-To: <20060226222217.GB17257@aerie.halcy0n.com>
User-Agent: Mutt/1.5.11
X-Spam-Score: -0.9 (/)
X-Archives-Salt: b9953949-6702-4981-828d-930ea3219f17
X-Archives-Hash: 7dfa53bdfce7edd672a576ff7a346b78


--adJ1OR3c6QgCpb/j
Content-Type: text/plain; charset=utf8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

My personal opinion here is that a _LOT_ of this should be common sense.
But just to put in my two pennies..

On Sun, Feb 26, 2006 at 05:22:17PM -0500, Mark Loeser <halcy0n@gentoo.org> =
wrote:
> * The QA team's purpose is to provide cross-herd assistance in keeping
>   the tree in a good state. This is done primarily by finding and pointing
>   out issues to maintainers and, where necessary, taking direct action.

Please clarify "neccessary". I don't want to see repeat occurances of
non-issues bogging down real work. Also, please define around this a
clear and documented policy so when its enforced, its well defended.

> * The QA team may also offer to fix obvious typos and similar minor
>   issues, and silence from the package maintainers can be taken as agreem=
ent in
>   such situations.

I have no objections, on the understanding that there is a definitive
understanding of whats being changed and legitimate things aren't
accidentally replaced.

> * In case of emergency, or if package maintainers refuse to cooperate,
>   the QA team may take action themselves to fix the problem.

This is part and parcel of your first point and should be included as
part of that. ie: definition of neccessary and surrounding policy.

> * In the event that a developer still insists that a package does not
>   break QA standards, an appeal can be made at the next council meeting. =
The
>   package should be dealt with per QA's request until such a time that a
>   decision is made by the council.

as above.

> * In the case of disagreement on policy among QA members, the majority
>   of established QA members must agree with the action.

Perhaps pushing it to an open forum on -dev/-core for consensus works
better here?

> * Just because a particular QA violation has yet to cause an issue does
>   not change the fact that it is still a QA violation.

Is this a statement or a policy? I assume that if this is policy the
non-visible issue would go about appropriate scrutany, and in turn a
long-term solution made in the situation where it is not easily
resolvable/avoidable.

> * 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.

This is the case at the moment anyways isn't it? And this shouldn't be
in a QA capacity but as a herd or individual. Perhaps this is better
suited in a different proposal?

> * The QA team will maintain a list of current "QA Standards".  The list
>   is not meant by any means to be a comprehensive document, but rather a
>   dynamic document that will be updated as new problems are discovered.
>=20

Can I suggest that such a document is also refered to by the policy
surrounding a violations resolution. Especially when considering a
violation which is not documented (and therefore can be fairly unknown)
so that violations not listed might be treated with more tact.

Thanks for presenting this to the list.
- John

--=20
Role:            Gentoo Linux Kernel Lead
Gentoo Linux:    http://www.gentoo.org
Public Key:      gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515


--adJ1OR3c6QgCpb/j
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)

iD8DBQFEAjWZNzVYcyGvtWURAnLBAKDMGJLHMFya7m4MJHlR/qXCPiNXQACg24Fy
2P9g+dexOmcfnfMdjgRH5PE=
=S0wW
-----END PGP SIGNATURE-----

--adJ1OR3c6QgCpb/j--
-- 
gentoo-dev@gentoo.org mailing list