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 ) id 1N6pdE-0001Yh-KE for garchives@archives.gentoo.org; Sat, 07 Nov 2009 18:03:24 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 997F7E0B13; Sat, 7 Nov 2009 18:03:23 +0000 (UTC) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.120]) by pigeon.gentoo.org (Postfix) with ESMTP id 7E9CAE0B13 for ; Sat, 7 Nov 2009 18:03:23 +0000 (UTC) Received: from linux1.localdomain ([76.183.49.63]) by cdptpa-omta02.mail.rr.com with ESMTP id <20091107180323132.GDLV6968@cdptpa-omta02.mail.rr.com>; Sat, 7 Nov 2009 18:03:23 +0000 Received: by linux1.localdomain (Postfix, from userid 1000) id 93BF143C03; Sat, 7 Nov 2009 12:03:22 -0600 (CST) Date: Sat, 7 Nov 2009 12:03:22 -0600 From: William Hubbs To: gentoo-dev@lists.gentoo.org Cc: qa@gentoo.org Subject: Re: [gentoo-dev] QA: package.mask policies Message-ID: <20091107180322.GA23301@linux1> Mail-Followup-To: gentoo-dev@lists.gentoo.org, qa@gentoo.org References: <200911071824.16651.scarabeus@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.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="LQksG6bCIzRHxTLp" Content-Disposition: inline In-Reply-To: <200911071824.16651.scarabeus@gentoo.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Archives-Salt: 5a549315-f528-4346-9526-51036503d0f0 X-Archives-Hash: 26e9cf4da5d99e076f5374cccf6074e1 --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, I'm not QA, but I'll go ahead and add my comments to this also. On Sat, Nov 07, 2009 at 06:24:10PM +0100, Tom???? Chv??tal wrote: > * Masking beta... > This masks are good if the software release is KNOWN to break previous=20 > behaviour or degrade user experience. Otherwise the software should not b= e=20 > masked (its TESTING for purpose, not stable). =20 Agreed. If it works and does not cause issues for users or degrade their experience, it should be in ~arch, not in p.mask. > Also the maintainer should watch if the testing branch is still relevant = (why=20 > on earth we have masked 4.0.3_p20070403 version of screen when newer 4.3 = is=20 > stable ;]) and remove the branch+mask when needed. =20 Definitely. If a newer version of a package is stable, or in ~arch for that matter, why do we still have the old version in the tree and masked while the newer version is unmasked? > * Masking live... > Heck no. This is not proper usage. Just use keywords mask. KEYWORDS=3D"".= =20 > Problem solved and the package.mask is smaller. (Note, in overlays do wha= t=20 > ever you want, since it does not polute the main mask from g-x86). =20 True. If we mask live ebuilds with KEYWORDS=3D"", there isn't a reason to put them in p.mask that I can think of. > * Masking stable releases... > Here i found most interesting stuff around (for example mask for testing = =66rom=20 > 2006, yeah not ~ material after 3 years?! :P) > There should be policy defined that you can add the new release under p.m= ask if=20 > you see it fit, but the mask can stay only for 6 months (less/more,=20 > suggestions?) and then it must be unmasked, or have really high activity = on=20 > tracker bug and good reasoning (mask for ruby-1.9 and so on). =20 Off the top of my head, I think this falls under category 1 above as well. If a new release of a package and everything that uses the new package can be installed in a way that does not degrade the user's experience if they want to use the older release, it doesn't need to be in p.mask. In general, I don't think a new release of a package should be added to p.mask unless it fits category 1 above. Things that have been "masked for testing" for years need to have a decision made about them -- keep them in the tree and unmask them or remove them. --=20 William Hubbs gentoo accessibility team lead williamh@gentoo.org --LQksG6bCIzRHxTLp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkr1tmoACgkQblQW9DDEZTh2GwCfSd0N8Lp/EXciBC623aq43pan CiMAnAhTbOzGJNn2qOPLXEZET2VRzoDH =HXIm -----END PGP SIGNATURE----- --LQksG6bCIzRHxTLp--