1 |
On Tue, Jan 14, 2014 at 08:36:10PM -0500, Michael Orlitzky wrote: |
2 |
> On 01/14/2014 08:23 PM, Tom Wijsman wrote: |
3 |
> > On Tue, 14 Jan 2014 20:11:24 -0500 |
4 |
> > Michael Orlitzky <mjo@g.o> wrote: |
5 |
> > |
6 |
> >> On 01/14/2014 08:08 PM, Tom Wijsman wrote: |
7 |
> >>> |
8 |
> >>> This is under the assumption that the user knows of the state of the |
9 |
> >>> stabilization worsening; if the user is unaware of that change, the |
10 |
> >>> "could have done anyway" might be less common and first something |
11 |
> >>> bad would need to happen before they realize the worsened |
12 |
> >>> stabilization. |
13 |
> >>> |
14 |
> >> |
15 |
> >> If I don't realize it, it ain't broke. |
16 |
> > |
17 |
> > So, you're going to wait for corruption, a security breach or something |
18 |
> > along those lines to happen first? |
19 |
> |
20 |
> I will wait for them to be *known*. |
21 |
> |
22 |
> Security stabilizations are already treated special, so while they'd |
23 |
> make a nice example here you don't get to invoke them =) |
24 |
> |
25 |
> It's highly unlikely that one day a stable piece of software is just |
26 |
> going to start corrupting data randomly when some other stable package |
27 |
> is updated. Why? Because arch testers have to test them before they go |
28 |
> stable! It's even more unlikely that upgrading to untested stuff would |
29 |
> be safer than staying put, which is really all I care about given a |
30 |
> choice between the two. |
31 |
> |
32 |
> For really bad cases like data corruption we already have procedures |
33 |
> that allow quick stabilization ("reasonable amount of time..."). All |
34 |
> we're really talking about here is forcing me to upgrade to an unstable |
35 |
> package for some features or bugfixes I don't care about. |
36 |
|
37 |
After the package has been sitting in ~arch for 90 days with an open |
38 |
stable request with no blockers that the arch team has not taken any |
39 |
action on. We are not talking about randomly yanking package versions, |
40 |
just doing something when arch teams are not responsive, and it seems |
41 |
that the cleanest thing to do would be to remove the old versions. |
42 |
|
43 |
William |