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 54DBD138247 for ; Wed, 15 Jan 2014 02:27:55 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 24CA2E0AB1; Wed, 15 Jan 2014 02:27:48 +0000 (UTC) Received: from juliette.telenet-ops.be (juliette.telenet-ops.be [195.130.137.74]) by pigeon.gentoo.org (Postfix) with ESMTP id D08E1E0A83 for ; Wed, 15 Jan 2014 02:27:46 +0000 (UTC) Received: from TOMWIJ-GENTOO ([94.226.55.127]) by juliette.telenet-ops.be with bizsmtp id E2Tm1n0012khLEN062Tm9m; Wed, 15 Jan 2014 03:27:46 +0100 Date: Wed, 15 Jan 2014 03:26:50 +0100 From: Tom Wijsman To: mjo@gentoo.org Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] rfc: revisiting our stabilization policy Message-ID: <20140115032650.6e720a07@TOMWIJ-GENTOO> In-Reply-To: <52D5E60A.80600@gentoo.org> References: <20140114213719.GA2684@laptop.home> <52D5B2CA.5030407@gentoo.org> <20140114223312.GA3337@laptop.home> <52D5BDAD.4030808@gentoo.org> <20140114231113.GA3393@laptop.home> <52D5DAB6.1000609@gentoo.org> <20140115020802.700b1568@TOMWIJ-GENTOO> <52D5E03C.3010900@gentoo.org> <20140115022337.4336618d@TOMWIJ-GENTOO> <52D5E60A.80600@gentoo.org> 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_/IOwgmGwu+ECR=HH2EDFqw/U"; protocol="application/pgp-signature" X-Archives-Salt: b2c4e8c4-ec53-493f-8bd0-7d9aeb8576f8 X-Archives-Hash: 7d212b372cfd2e851cd13e1e9986e1ea --Sig_/IOwgmGwu+ECR=HH2EDFqw/U Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 14 Jan 2014 20:36:10 -0500 Michael Orlitzky wrote: > On 01/14/2014 08:23 PM, Tom Wijsman wrote: > > On Tue, 14 Jan 2014 20:11:24 -0500 > > Michael Orlitzky wrote: > >=20 > >> On 01/14/2014 08:08 PM, Tom Wijsman wrote: > >>> > >>> This is under the assumption that the user knows of the state of > >>> the stabilization worsening; if the user is unaware of that > >>> change, the "could have done anyway" might be less common and > >>> first something bad would need to happen before they realize the > >>> worsened stabilization. > >>> > >> > >> If I don't realize it, it ain't broke. > >=20 > > So, you're going to wait for corruption, a security breach or > > something along those lines to happen first? >=20 > I will wait for them to be *known*. The question is whether you or the user will want to wait whether it *happens* to you; of course you can restrict yourself to what's known, but you cannot keep track of *everything that's known* out there easily. And even if you were hundred security experts tracking everything; that wouldn't reflect the user, neither our security team. Just like stabilization, efforts are limited in security; so, you're going to have to rely on a problem similar to that of WilliamH. Besides that, *unknown* things could happen to you too; are you sure you definitely want to wait for that to happen? Or rather upgrade? > Security stabilizations are already treated special, so while they'd > make a nice example here you don't get to invoke them =3D) Assuming every security bug is known by the public. =3D) > It's highly unlikely that one day a stable piece of software is just > going to start corrupting data randomly when some other stable package > is updated.=20 That is exactly one of the popular ways to introduce incompatibilities; and thus, it can cause corruption or something less worse than that to happen. There are other things like data loss, like we see happen more often with hangs and crashes; corruption is just one example of many... > Why? Because arch testers have to test them before they go stable! Testing all reverse dependencies of sys-libs/glibc or one of the other important libraries is rather impossible given the lack of resources, you're relying on the same problem WilliamH has here; well, you could select a sample set of them perhaps, but you cannot assure there to be no regression in a small set of the reverse dependencies. "Arch testers have to test them before they go stable!" Why? Because of the lack of upper bounds on deps, neither do they have proper slots, and not to forget that stabilizations are laggy; interesting! > It's even more unlikely that upgrading to untested stuff would > be safer than staying put, which is really all I care about given a > choice between the two. untested (subjective) !=3D unstable (objective), safer (subjective) !=3D stable (objective), I care (subjective) !=3D users care (objective). There's doubt in this paragraph, but no constructive reasoning. You are focusing on a single solution instead of focusing on the actual problem and the other solutions; while you may very well care for one solution not to happen, that doesn't ensure that we keep what we have. If you tell us what you want, we can do something about it. If you tell us what you don't want, but don't tell that to us based on what you want; it becomes a vote without any value instead than a discussion. > For really bad cases like data corruption we already have procedures > that allow quick stabilization ("reasonable amount of time..."). Turn this sentence around and you'll see how quick stabilization leads to less data corruption. > All we're really talking about here is forcing me to upgrade to an > unstable package for some features or bugfixes I don't care about. You are focusing on a single solutions instead of ... [see above]. --=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_/IOwgmGwu+ECR=HH2EDFqw/U Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJS1fHqAAoJEJWyH81tNOV9Pp0H/A9pMaZmN+HxLYQs4jTGBdFy vcWTFtSpiuBEdQliGmQL2N5MGUhvOJkCngpf1lA5Xq2sHOAak5niJ/8wHIFRYz7r U+3irjznmc6Bxwg0FBrA8jLktmRncu/hDzpQQVYtNcpuRFSDvebiRCd2lhasEBP+ oyFT6a2Hc4oh8CA9rLOU0kB88EmPY2r2u4bnxZbr9/GVBjvMlhRPc7Km0YWs1h7I T41JD34xZKfgMtjH2tt6GB2dWmHka7CFPdh+CTSmXrqSPKaA6IaW7DSzh1w5D5MU 6uHppuwI7gLOmjGJdgNcauIhIrwjconNAgEmJqUvtjEKh+iRMBUwLciCoRrslCU= =+zen -----END PGP SIGNATURE----- --Sig_/IOwgmGwu+ECR=HH2EDFqw/U--