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 D0C821392EF for ; Mon, 30 Jun 2014 20:51:26 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A9FB7E0A7E; Mon, 30 Jun 2014 20:51:06 +0000 (UTC) Received: from smarthost01c.mail.zen.net.uk (smarthost01c.mail.zen.net.uk [212.23.1.5]) by pigeon.gentoo.org (Postfix) with ESMTP id B46BEE0A53 for ; Mon, 30 Jun 2014 20:51:05 +0000 (UTC) Received: from [62.3.120.142] (helo=NeddySeagoon_Static) by smarthost01c.mail.zen.net.uk with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1X1iXZ-000Djm-3b for gentoo-dev@lists.gentoo.org; Mon, 30 Jun 2014 20:51:05 +0000 Date: Mon, 30 Jun 2014 21:50:35 +0100 From: Roy Bamford Subject: Re: [gentoo-dev] package.mask vs ~arch To: gentoo-dev@lists.gentoo.org In-Reply-To: <20140630040153.GA668@linux1> (from williamh@gentoo.org on Mon Jun 30 05:01:53 2014) X-Mailer: Balsa 2.4.14 Message-Id: <1404161463.1680.0@NeddySeagoon_Static> 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="=-duW6UjslLEnzW/liXPMf" X-Originating-smarthost01c-IP: [62.3.120.142] X-Archives-Salt: 8604b0e8-9bc4-4d68-9b8a-761203b5752c X-Archives-Hash: a74d05d4f39e6bd6fd324ee19b0bd6a6 --=-duW6UjslLEnzW/liXPMf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2014.06.30 05:01, 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, > then > > > 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=20 > package, > > or any aspect of the package? Do we want it to break completely=20 > 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=20 > ~arch > without testing it, but ~arch users are running ~arch with the > understanding that their systems will break from time to time and=20 > they > are expected to be able to deal with it when/if it happens. ~arch is > not a second stable branch. >=20 > > 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. >=20 > *snip* >=20 > > I guess the question is, what exactly are we trying to fix? Even=20 > if > > occasionally a maintainer drops the ball and leaves something=20 > masked > > for a year, how is that different from a maintainer dropping the > ball > > and not adding a new release to the main tree for a year? Would we > be > > better off if Docker 1 wasn't in the tree at all? If it happened=20 > to > > have a known issue would ~arch users be better off if some other=20 > dev > > came along and helpfully added it to the tree unmasked no realizing > > that somebody else was already working on it? >=20 > Take a look at profiles/package.mask. You will see many packages in > there with the description, "masked for testing" on their masks, with > no > bug references, that have been there for multiple years. My view is=20 > we > should either get those masks resolved or boot the affected > packages/versions out of the tree. If they haven't received > rudimentary > testing by now, it is pretty obvious that no one cares about them. >=20 > William >=20 >=20 Once upon a time, not so long ago I don't remember it, there were very=20 few overlays. At that time, there was always a lot of packages in the=20 tree "masked for testing". At that time, well before layman, overlays=20 were inconvenient.=20 As overlays have become more widespread and used as a way to lower the=20 barrier to contributing directly to Gentoo, there are fewer packages=20 "masked for testing". I like the old way, it avoids installing yet another overlay but=20 clearly others feel differently or there would not be so many overlays=20 to choose from. The reality is, both ways work for me. Pragmatically, its not practical to merge all of the overlays into the=20 tree, then ban overlays. That would be a return to the old way. This just represents a change of workflow with time. The question then is do we need to formalise the changed workflow, or=20 can both be allowed to continue side by side? --=20 Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees = --=-duW6UjslLEnzW/liXPMf Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABAgAGBQJTsc23AAoJEFZf0zWq3OcJ+jgQAInqhjPLiT4/S6LqVzHcanO9 R19BcxChoSsvr9P4e8g5LftUtWB3wrTEHR+4PJfm6nTynue1/nPFmSYWeE9FlwaA 7fVEGcfBovrYz/woDsp5m3UfrdsGV3nWmctWXBBoHyBbIrAuWqAd6MiTgakjE3f+ qKmEWK7gKAXWJC8RSCEjOwfJuPgZ1EHNj0fhTbE+/sl6hvpZaTXXeXsSR108C2hH aJ/mmjm2snk0ru814rMwT9NZuAKUggu2IgmEVVjUtb9//k1lZkALaA8GeoSIWduN E3tEisTDfFWP3jlryebil+2Xuu4Z7rJ8mMaHy+n4PYMaw+6BMNlRJ4X2CKl6NIQQ Bn/Ad95jEIlfcH0836Nb3ee+YCvGShwI56VcMIa3ApCMb1o90s46Bv/s5uZOxQIT EFnuzK0vslcqdN5yFAnd361cEkESTbt7ZKeW78xjU8EBUQ7QuI8cyEeLFAKVKI6I DF0Ud1ITpxs38wa1ohtRCZo8nl/YnkKMI5jYqlCCzhmpjJrTDWF5ITf9CfJJVIOF /w3P1UYMNYixeqf3U+k44Sog6OYsoGZ4T2iihWnbLKR2ozQHPRHHomW306d0WdJm Ze5phmQx1kkZK6/QLMkxgmsBP5NG5cLWKKSPzwcFV5ReIuc5GijyHhXWrABsvuuH prLcZzYPvoKvETBIgwOy =mVHL -----END PGP SIGNATURE----- --=-duW6UjslLEnzW/liXPMf--