From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 7AC0113877A for ; Mon, 30 Jun 2014 14:13:25 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8E05FE093E; Mon, 30 Jun 2014 14:13:15 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 925AFE0916 for ; Mon, 30 Jun 2014 14:13:14 +0000 (UTC) Received: from rook (unknown [96.241.16.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: tetromino) by smtp.gentoo.org (Postfix) with ESMTPSA id 503B833FB3E for ; Mon, 30 Jun 2014 14:13:13 +0000 (UTC) Message-ID: <1404137518.29783.3.camel@rook> Subject: Re: [gentoo-dev] package.mask vs ~arch From: Alexandre Rostovtsev To: gentoo-dev@lists.gentoo.org Date: Mon, 30 Jun 2014 10:11:58 -0400 In-Reply-To: <53B14A33.7040108@gentoo.org> References: <20140630040153.GA668@linux1> <53B14A33.7040108@gentoo.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Xr9aHL3qPNotJJdEjv5O" X-Mailer: Evolution 3.12.3 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 X-Archives-Salt: a67d916c-9293-475b-a6dd-94fd7de5dea0 X-Archives-Hash: 3fb945eda8c7cb313ee6eb586a1934cf --=-Xr9aHL3qPNotJJdEjv5O Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2014-06-30 at 11:29 +0000, hasufell wrote: > > I agree that masking for testing is like having a 3rd branch, but I'm > > not convinced that this is a bad thing. >=20 > I have to reiterate: > * increases the workload, because we are effectively running 3 branches > * decreases the amount of testing for that time period, because... it's > masked > * causes confusion (see this thread) A branch is is supposed to be internally consistent: for any X and Y, the latest version of X from a given branch is in theory compatible with the latest version of Y from the same branch. If they are not compatible, there should be a bug that somebody is actively working on resolving, or a blocker dependency, and such blockers ought to be relatively rare to make things easy for human minds and package managers. Masked packages are not a third branch. Some packages are hardmasked for being untested, some for impossible-to-fix bugs, some are known to break a reverse dependency and are waiting for that reverse dependency to be updated, some are lastrited for removal in 30 days. There is absolutely no expectation that all masked packages are compatible with each other. > * decreases the quality of our stable branch, because people suddenly > expect the unstable branch to be ...stable and don't bother with filing > stabilization requests anymore Stablereq for wine-1.6.2 was filed in February. It got stabilized on amd64 exactly 4 months later. Security stablereq for freetype-2.5.3-r1 was filed in March for all arches. Thus far, only hppa and ia64 stabilized it. People don't bother with filing stabilization requests because they realize that arch teams usually have a long backlog of existing requests, and might take weeks/months to get to your new request. Especially if your new request depends on other stablereqs. --=-Xr9aHL3qPNotJJdEjv5O Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABAgAGBQJTsXAuAAoJEKRDAQ9PHUhgUYEP/1ZmBUCypmp2UuH5Nbu4YWsB u+nGaRQNunyqiTod7CckWAWvaMhSdrL1kTkHThuWAP7BzY9GOi65MAtlan8usR7S K9JNU4li+ndD8i6PXnyvsRNiuJ/4wCvqIISE/7uVTY0mMdOU+XGkcAWgUhbBtCOz zOce8qdJZYtQytZlcVL8FqUDbAS2sYTfQHvssGH26j5tyOAq9wZb9X1G1ilnlNPE G6VLNOYjnGa5cjfnLDeXgapa6yZCOrzAOU9ELKc6fDpEnUxg1ebBQUXEfjMYcOO+ ivbo/Af2GygZs64yutdF7uzOl0NJRJn4htcMzYOb7YK6M4GhK3Gqy+qnTflhdFCM iqdEE1w5OAavrQwI/v97tvMEoNyjC3czPf5fnnROsOvNlNUnWdObdQKEtRi5hZpD DHLndjJ4Dv2LGTGoq9D++9b3ZNLCb5c0ct97lBasM5eTrarbnpNuaBysEAn5y9VJ YzSfhfVHfpS8vJyuZR+OeKOCXn7gSPeDGPqNlkSb3dsaYTikpfArIKzDZPmS4Rh8 azIqCkAoSBU+csT2ktTY6LQ1tN1EGjf3UIkcjkQrSy7I6WcVLHOW2vC/EnX1BJJR GHsjtEPRfG6f8qOzANqPWB2mUckk7PC77fdyCprlsPDR6GDYLRC7WwrlZDOse9Hv smdJUvML42aVsBFU9x8D =QI6m -----END PGP SIGNATURE----- --=-Xr9aHL3qPNotJJdEjv5O--