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 1F86213877A for ; Mon, 30 Jun 2014 06:05:43 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9A907E099C; Mon, 30 Jun 2014 06:05:37 +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 8EC25E0925 for ; Mon, 30 Jun 2014 06:05:36 +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 9059333FF14 for ; Mon, 30 Jun 2014 06:05:35 +0000 (UTC) Message-ID: <1404108260.29783.1.camel@rook> Subject: Re: [gentoo-dev] package.mask vs ~arch From: Alexandre Rostovtsev To: gentoo-dev@lists.gentoo.org Date: Mon, 30 Jun 2014 02:04:20 -0400 In-Reply-To: <20140630040153.GA668@linux1> References: <20140630040153.GA668@linux1> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-0ez6v3oHdw5a/AiJphe0" 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: c3517eac-5f70-4c29-bd7d-649c35db2c46 X-Archives-Hash: 98dd638a868f1a32b9eb591d05f271e5 --=-0ez6v3oHdw5a/AiJphe0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, 2014-06-29 at 23:01 -0500, William Hubbs wrote: > All, >=20 > I am starting a new thread so we don't refer to a specific package, but I > am quoting Rich and hasufell from the previous masking thread. >=20 > On Sun, Jun 29, 2014 at 10:04:54AM -0400, Rich Freeman wrote: > > On Sun, Jun 29, 2014 at 8:36 AM, hasufell wrote: > > > This is still too vague for me. If it's expected to be short-term, th= en > > > it can as well just land in ~arch. > >=20 > > A package that hasn't been tested AT ALL doesn't belong in ~arch. > > Suppose the maintainer is unable to test some aspect of the package, > > or any aspect of the package? Do we want it to break completely for > > ~arch? In that event, nobody will run ~arch for that package, and > > then it still isn't getting tested. >=20 > I'm not saying that we should just randomly throw something into ~arch > without testing it, but ~arch users are running ~arch with the > understanding that their systems will break from time to time and they > are expected to be able to deal with it when/if it happens. ~arch is > not a second stable branch. I realize that not everybody agrees with me, but I see ~arch as a "semi-stable" branch - an internally consistent branch for people who don't feel like maintaining a horrific mess of keywords and masks in their /etc/portage and don't want to wait weeks/months for bugfixes to their favorite ebuilds to be marked stable by overworked arch teams, and who don't mind seeing an occasional build failure or crash as a consequence of standing closer to the bleeding edge. In my view, experimental work not ready for general exposure should be kept in overlays and/or the main tree's package.mask, depending on how the particular project's workflow is organized. > > I agree that masking for testing is like having a 3rd branch, but I'm > > not convinced that this is a bad thing. ~arch should be for packages > > that have received rudimentary testing and which are ready for testing > > by a larger population. Masking should be used for packages that > > haven't received rudimentary testing - they might not have been tested > > at all. >=20 > The concern with this argument is the definition of rudimentary testing > is subjective, especially when a package supports many possible > configurations. >=20 > I think some packages need wide testing before they go stable, and that > is where ~arch can help out. >=20 > In particular, I would argue that for system-critical packages, users > should be very careful about running ~arch unless they know what the > fallout can be. At any given stability level, a system-critical library ideally ought to be better-tested than, say, a game or a media player. In practice, this sometimes doesn't happen, because some system-critical library maintainers don't care about ~arch users and dump experimental code in their laps, and in my view that's a bad thing because it encourages users to come up with ad-hoc mixed arch/~arch setups which have *never* been tested by any developer. --=-0ez6v3oHdw5a/AiJphe0 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 iQIcBAABAgAGBQJTsP3kAAoJEKRDAQ9PHUhgaW0P/juIiecI5O3awXsEkdOzLKJt AMsIAFwLJyZqwQNpUtApqGuy1swRalLVUi7lGpcHJaTtSlfjcusfLHPpPoxVRWCu tBog5Bu/ZX0wmbJRgL/lDuoj9nEEfMuGMCRl6Gmf9+7TRy46Z/w8iPUpdl0efjeu /9VQtzXABphS0V5BfRkcQv92tvdeBaqIUOJF52nwia1wOQCQHjInHi+PyNRzgELn eHr9A/pi0LVLvgAZ7f5Q3avxe2xrlIt2DkuGzW8FNlDjuK8wjXlD9yMHfLefNvAk UMBYlyaBQikQYPYQ9igK/JkcYqXjQnWpZQYr4zfwxDLG6+hn14OY9zKxQXhNzJK4 KV2fZUgRg6ZZEO1ONn/Gft08AyVLGOYsuYufYMiKUqSZuriiIRxjfdL+CB9qce6/ XrYwX8Jnx/dYpKrRYXEov18fJIOvPJbOf54tSf91EOS6f7+KRMY1pF3TP1I7plbT dUax7NLr9d9k0TNDHSWlyDtH/8UDgPu8UcArpmsEoaCMNwJcIQ3glbYQMQGuICxz XMtyDRsMlVKdaJH4wBAVkyMks4IR1ztVpFrWWsiT3LciFvd6dk/swOUkHEpFUJIJ +hxtiU+qK6IWjEV4OztyooipYQ97lh7bDsFkreXiqQQ3UcwhGw+4XZXGiWrtonfy gxhyWqlwS9EtUNad+PG3 =mpXQ -----END PGP SIGNATURE----- --=-0ez6v3oHdw5a/AiJphe0--