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

[Christopher Head]

On Thu, 16 Jan 2014 23:44:42 +0100
Tom Wijsman <TomWij@g.o> wrote:

> > If I don’t, why do I care if the package is a year old? I lose none
> > of my time to use the old version, since it does all I want;
>
> This is under the assumption that the old version has no further
> implications, which is a false assumption; because the older a stable
> ebuild get, the higher the chance is that it becomes incompatible with
> its libraries and/or causes blockers. Even further, a security bug for
> an old version of a library it depends on could cause its removal.

Right, of course things can become incompatible—but the distro handles
that by either leaving old enough version of e.g. libraries around that
the latest stable versions of their reverse dependencies don’t break,
or, in exceptional cases (e.g. security), by breaking things
intentionally if necessary, thus telling me that there’s a problem.

> > I lose a
> > nonzero amount of time if I get a version which breaks things (even
> > if the only time I lose is the time it takes to downgrade),
>
> Depends on whether the stable version is as perfect as one thinks it
> is; an upgrade can go two ways, it improves or regresses. (Well, three
> ways as it can stay the same, but that wouldn't demonstrate the point)

Well, yes. I was considering the case of a stable version that does
work well. If the stable version has a bug that affects me, I won’t be
using it—I’ll pull in an unstable version that fixes the bug, and then
get back to stable ASAP after that.

> > so it’s in my best interest to use the stable versions of such
> > packages, even if they’re a month, a year, or three years old.
>
> Based on what you know, what you need and that you can resist change;
> yes, but this doesn't take into account what you don't know, you don't
> know you need and the improvements that change can bring.
>
> While it doesn't happen often, some people will say "if I knew this
> earlier, I would have already upgraded a long while ago"; either
> because the new version brings something good, or the old version has
> a regression they were not aware of yet or came due to
> incompatibility...

Sure, it was wrong to say it takes *no* time, but I think less time
than sticking to the bleeding edge and having things break from time to
time. My experience with stable has been that bugs (at least bugs that
I encounter) are rare and, most importantly, bugs are *very* rare in the
important packages that are hard to fix (glibc, openrc, gentoo-sources,
openssh for servers, etc.). I understand they’re fairly rare in unstable
as well, but I would expect a bit more common than in stable.

If stable really is falling behind and the backlog is always growing,
obviously something has to be done. I just don’t want “something” to
mean “don’t have a stable tree”. The stable tree provides me with a
benefit. If standards have to slip a bit to maintain timeliness, then
I’d prefer a stable tree that’s as stable as practical, accepting
reality—perhaps where users are able to submit reports of working
packages, or where we let platform-agnostic packages be stabilized
after one arch has tested, or various of the other suggestions in this
thread. Just not no stable tree at all.
-- 
Christopher Head