| 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? |
| 18 |
|
| 19 |
I will wait for them to be *known*. |
| 20 |
|
| 21 |
Security stabilizations are already treated special, so while they'd |
| 22 |
make a nice example here you don't get to invoke them =) |
| 23 |
|
| 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. |
| 30 |
|
| 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. |
Archives