Gentoo Archives: gentoo-dev

From: Tom Wijsman <TomWij@g.o>
To: mjo@g.o
Cc: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] rfc: revisiting our stabilization policy
Date: Wed, 15 Jan 2014 02:27:55
Message-Id: 20140115032650.6e720a07@TOMWIJ-GENTOO
In Reply to: Re: [gentoo-dev] rfc: revisiting our stabilization policy by Michael Orlitzky
1 On Tue, 14 Jan 2014 20:36:10 -0500
2 Michael Orlitzky <mjo@g.o> wrote:
4 > On 01/14/2014 08:23 PM, Tom Wijsman wrote:
5 > > On Tue, 14 Jan 2014 20:11:24 -0500
6 > > Michael Orlitzky <mjo@g.o> wrote:
7 > >
8 > >> On 01/14/2014 08:08 PM, Tom Wijsman wrote:
9 > >>>
10 > >>> This is under the assumption that the user knows of the state of
11 > >>> the stabilization worsening; if the user is unaware of that
12 > >>> change, the "could have done anyway" might be less common and
13 > >>> first something bad would need to happen before they realize the
14 > >>> worsened stabilization.
15 > >>>
16 > >>
17 > >> If I don't realize it, it ain't broke.
18 > >
19 > > So, you're going to wait for corruption, a security breach or
20 > > something along those lines to happen first?
21 >
22 > I will wait for them to be *known*.
24 The question is whether you or the user will want to wait whether it
25 *happens* to you; of course you can restrict yourself to what's known,
26 but you cannot keep track of *everything that's known* out there easily.
28 And even if you were hundred security experts tracking everything; that
29 wouldn't reflect the user, neither our security team. Just like
30 stabilization, efforts are limited in security; so, you're going to
31 have to rely on a problem similar to that of WilliamH.
33 Besides that, *unknown* things could happen to you too; are you sure you
34 definitely want to wait for that to happen? Or rather upgrade?
36 > Security stabilizations are already treated special, so while they'd
37 > make a nice example here you don't get to invoke them =)
39 Assuming every security bug is known by the public. =)
41 > It's highly unlikely that one day a stable piece of software is just
42 > going to start corrupting data randomly when some other stable package
43 > is updated.
45 That is exactly one of the popular ways to introduce incompatibilities;
46 and thus, it can cause corruption or something less worse than that to
47 happen. There are other things like data loss, like we see happen more
48 often with hangs and crashes; corruption is just one example of many...
50 > Why? Because arch testers have to test them before they go stable!
52 Testing all reverse dependencies of sys-libs/glibc or one of the other
53 important libraries is rather impossible given the lack of resources,
54 you're relying on the same problem WilliamH has here; well, you could
55 select a sample set of them perhaps, but you cannot assure there to be
56 no regression in a small set of the reverse dependencies.
58 "Arch testers have to test them before they go stable!" Why? Because
59 of the lack of upper bounds on deps, neither do they have proper slots,
60 and not to forget that stabilizations are laggy; interesting!
62 > It's even more unlikely that upgrading to untested stuff would
63 > be safer than staying put, which is really all I care about given a
64 > choice between the two.
66 untested (subjective) != unstable (objective),
67 safer (subjective) != stable (objective),
68 I care (subjective) != users care (objective).
70 There's doubt in this paragraph, but no constructive reasoning.
72 You are focusing on a single solution instead of focusing on the actual
73 problem and the other solutions; while you may very well care for one
74 solution not to happen, that doesn't ensure that we keep what we have.
76 If you tell us what you want, we can do something about it. If you tell
77 us what you don't want, but don't tell that to us based on what you
78 want; it becomes a vote without any value instead than a discussion.
80 > For really bad cases like data corruption we already have procedures
81 > that allow quick stabilization ("reasonable amount of time...").
83 Turn this sentence around and you'll see how quick stabilization leads
84 to less data corruption.
86 > All we're really talking about here is forcing me to upgrade to an
87 > unstable package for some features or bugfixes I don't care about.
89 You are focusing on a single solutions instead of ... [see above].
91 --
92 With kind regards,
94 Tom Wijsman (TomWij)
95 Gentoo Developer
97 E-mail address : TomWij@g.o
98 GPG Public Key : 6D34E57D
99 GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D


File name MIME type
signature.asc application/pgp-signature