Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Tom Wijsman]

On Tue, 14 Jan 2014 20:36:10 -0500
Michael Orlitzky <mjo@g.o> wrote:

> On 01/14/2014 08:23 PM, Tom Wijsman wrote:
> > On Tue, 14 Jan 2014 20:11:24 -0500
> > Michael Orlitzky <mjo@g.o> wrote:
> >
> >> 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.
> >
> > So, you're going to wait for corruption, a security breach or
> > something along those lines to happen first?
>
> 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 =)

Assuming every security bug is known by the public. =)

> 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.

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) != unstable   (objective),
safer    (subjective) != stable     (objective),
I care   (subjective) != 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].

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@g.o
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D