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 2B07D13827E for ; Fri, 24 Jan 2014 18:27:58 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6EA47E0B29; Fri, 24 Jan 2014 18:27:52 +0000 (UTC) Received: from baptiste.telenet-ops.be (baptiste.telenet-ops.be [195.130.132.51]) by pigeon.gentoo.org (Postfix) with ESMTP id 4B749E084A for ; Fri, 24 Jan 2014 18:27:51 +0000 (UTC) Received: from TOMWIJ-GENTOO ([94.226.55.127]) by baptiste.telenet-ops.be with bizsmtp id HuTq1n00G2khLEN01uTqNa; Fri, 24 Jan 2014 19:27:50 +0100 Date: Fri, 24 Jan 2014 19:26:41 +0100 From: Tom Wijsman To: slong@rathaus.eclipse.co.uk Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy Message-ID: <20140124192641.5677cc51@TOMWIJ-GENTOO> In-Reply-To: <20140124104605.GA19957@rathaus.eclipse.co.uk> References: <52D5E60A.80600@gentoo.org> <20140115020934.GA3886@laptop.home> <52D5F0BF.3060305@gentoo.org> <20140115024604.GA3952@laptop.home> <20140115232804.1c26beda@kruskal.home.chead.ca> <20140116234442.27c361d1@TOMWIJ-GENTOO> <20140119143157.72fc0e91@kruskal.home.chead.ca> <20140120014713.2cafc257@TOMWIJ-GENTOO> <20140123181242.GA17827@rathaus.eclipse.co.uk> <20140123201333.71e52bfc@TOMWIJ-GENTOO> <20140124104605.GA19957@rathaus.eclipse.co.uk> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.22; x86_64-pc-linux-gnu) 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; boundary="Sig_/e.8KZApDElcMjfcaYKzG6la"; protocol="application/pgp-signature" X-Archives-Salt: 729cc104-2ea1-4397-bdd7-acad80f4eb5c X-Archives-Hash: 4980dbe6406f6f4767059d3051e69a6a --Sig_/e.8KZApDElcMjfcaYKzG6la Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 24 Jan 2014 10:46:06 +0000 "Steven J. Long" wrote: > Tom Wijsman wrote: > > "Steven J. Long" wrote: > > > What? Without a stable tree, Gentoo is useless afaic. > >=20 > > It moves us closer to upstream releases, a little more bleeding > > edge; a lot of users and developers run that already, it is found > > to be useful. >=20 > What? More vague. As are many of your philosophical statements in > later and prior mails, so I'll ignore those. It is reality; and thus, without a stable tree, Gentoo is still useful for a lot of users and developers. What is vague about that? > > > I don't think that's what was being proposed, though. The > > > question was really the old complaint about slow architectures; > > > the "-* arch" solution sounds like the most reasonable definition > > > of "dropping" keywords, in the absence of AT communication > > > otherwise. > >=20 > > Dropping keywords and specifying -* are a world apart of each other. >=20 > That's why it's in quotes. Why is there at all if you intend it to be irrelevant to this thread? > > The former means that it is not ready for wide stable or testing > > users, the latter means that it has been tested to not work at all; > > furthermore, we need to explicitly specify which arches in that > > case. >=20 > You're missing the point, again. The question was what does "dropping > keywords" mean, when the maintainer has stabilised a newer version on > the arch/s s/he has available, but feels that slower archs are holding > up that process. Where is that question?=20 > I'm slightly at a loss as to why it's such a big deal to just leave > the old ebuild as-is, given that anyone on a stabled arch should > upgrade automatically. It is when you are running the arch that only has the old version. > But given that the maintainer feels they don't want that old ebuild > around, and that the arch in question has not got round to testing the > new one, for whatever reason (it's their call, after all, as to how > their arch progresses), instead of simply removing that ebuild, or > bumping it to unstable (which makes zero sense), just leave it stable > on the slow arch/s in question, and remove the others. There are situations (security, stability, incompatibility) where keeping it in place becomes a much harder task; at which point, removal is bound to happen. At that point, such action is required. It becomes faster than you think; if you depend on a library, and the compatible range of that library gets wiped by a security bug, your package will suddenly depend on an incompatible newer stabilized version of the library at which point you are up for either a lot of hard work or plain out starting the progress of masking and removing it. > This seems like a rarity, but when it's an issue, people get annoyed > on either side. The solution proposed by the ARM team, Where is this solution? > seems like a simple way round, and indicates clearly to anyone > perusing the ebuild, that a newer version needs stabling on the > "slow" archs. Masking works fine for that too; what this does is make clear to the user that (1) the current stable version has breakage for a specific reason, (2) a newer stable version is not yet available and (3) that the user can choose to keep the breakage or upgrade to an unstable version. > By all means, raise technical objections; just not a philosophical > one. Where are these philosophical objections? --=20 With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : TomWij@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D --Sig_/e.8KZApDElcMjfcaYKzG6la Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJS4rBhAAoJEJWyH81tNOV9J8cH/jJRaIthOHLeDEes7IVoYP1X MnXQf/XlPjesHa7Q/g6nQosTnZQtlckrOqiHXubBB2oPfvtiZvaZg2zkPfnjHY0C vqMwSDYTJ3ceY/lSgnp2ugvh+O2y1/wLqeAuJt9prfxpvaSHzp8X07KCWgtmOUhM 1UvrkwTJbTCepu4b7uSexWiXUpS/WFvEEAwp+UwgCqLnTZMfxC4YPE8CLMEucwMt eZFlCrKBHJJRtiTeUHfqXc7ajMthfK5x5ZygphAmKCV8+6LHAcrWQxF4aqqWGUE+ D3xUV0Ddz7d9iW41vFD3pml0HxnMWQg29CB1YA48tU/7dwYKYitWbXMHsWNgXWo= =vX3x -----END PGP SIGNATURE----- --Sig_/e.8KZApDElcMjfcaYKzG6la--