Gentoo Archives: gentoo-dev

From: Michael Orlitzky <mjo@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] rfc: revisiting our stabilization policy
Date: Wed, 15 Jan 2014 01:36:19
In Reply to: Re: [gentoo-dev] rfc: revisiting our stabilization policy by Tom Wijsman
1 On 01/14/2014 08:23 PM, Tom Wijsman wrote:
2 > On Tue, 14 Jan 2014 20:11:24 -0500
3 > Michael Orlitzky <mjo@g.o> wrote:
4 >
5 >> On 01/14/2014 08:08 PM, Tom Wijsman wrote:
6 >>>
7 >>> This is under the assumption that the user knows of the state of the
8 >>> stabilization worsening; if the user is unaware of that change, the
9 >>> "could have done anyway" might be less common and first something
10 >>> bad would need to happen before they realize the worsened
11 >>> stabilization.
12 >>>
13 >>
14 >> If I don't realize it, it ain't broke.
15 >
16 > So, you're going to wait for corruption, a security breach or something
17 > along those lines to happen first?
19 I will wait for them to be *known*.
21 Security stabilizations are already treated special, so while they'd
22 make a nice example here you don't get to invoke them =)
24 It's highly unlikely that one day a stable piece of software is just
25 going to start corrupting data randomly when some other stable package
26 is updated. Why? Because arch testers have to test them before they go
27 stable! It's even more unlikely that upgrading to untested stuff would
28 be safer than staying put, which is really all I care about given a
29 choice between the two.
31 For really bad cases like data corruption we already have procedures
32 that allow quick stabilization ("reasonable amount of time..."). All
33 we're really talking about here is forcing me to upgrade to an unstable
34 package for some features or bugfixes I don't care about.