Gentoo Archives: gentoo-dev

From: Christopher Head <chead@×××××.ca>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] rfc: revisiting our stabilization policy
Date: Sun, 19 Jan 2014 22:32:15
In Reply to: Re: [gentoo-dev] rfc: revisiting our stabilization policy by Tom Wijsman
1 On Thu, 16 Jan 2014 23:44:42 +0100
2 Tom Wijsman <TomWij@g.o> wrote:
4 > > If I don’t, why do I care if the package is a year old? I lose none
5 > > of my time to use the old version, since it does all I want;
6 >
7 > This is under the assumption that the old version has no further
8 > implications, which is a false assumption; because the older a stable
9 > ebuild get, the higher the chance is that it becomes incompatible with
10 > its libraries and/or causes blockers. Even further, a security bug for
11 > an old version of a library it depends on could cause its removal.
13 Right, of course things can become incompatible—but the distro handles
14 that by either leaving old enough version of e.g. libraries around that
15 the latest stable versions of their reverse dependencies don’t break,
16 or, in exceptional cases (e.g. security), by breaking things
17 intentionally if necessary, thus telling me that there’s a problem.
19 > > I lose a
20 > > nonzero amount of time if I get a version which breaks things (even
21 > > if the only time I lose is the time it takes to downgrade),
22 >
23 > Depends on whether the stable version is as perfect as one thinks it
24 > is; an upgrade can go two ways, it improves or regresses. (Well, three
25 > ways as it can stay the same, but that wouldn't demonstrate the point)
27 Well, yes. I was considering the case of a stable version that does
28 work well. If the stable version has a bug that affects me, I won’t be
29 using it—I’ll pull in an unstable version that fixes the bug, and then
30 get back to stable ASAP after that.
32 > > so it’s in my best interest to use the stable versions of such
33 > > packages, even if they’re a month, a year, or three years old.
34 >
35 > Based on what you know, what you need and that you can resist change;
36 > yes, but this doesn't take into account what you don't know, you don't
37 > know you need and the improvements that change can bring.
38 >
39 > While it doesn't happen often, some people will say "if I knew this
40 > earlier, I would have already upgraded a long while ago"; either
41 > because the new version brings something good, or the old version has
42 > a regression they were not aware of yet or came due to
43 > incompatibility...
45 Sure, it was wrong to say it takes *no* time, but I think less time
46 than sticking to the bleeding edge and having things break from time to
47 time. My experience with stable has been that bugs (at least bugs that
48 I encounter) are rare and, most importantly, bugs are *very* rare in the
49 important packages that are hard to fix (glibc, openrc, gentoo-sources,
50 openssh for servers, etc.). I understand they’re fairly rare in unstable
51 as well, but I would expect a bit more common than in stable.
53 If stable really is falling behind and the backlog is always growing,
54 obviously something has to be done. I just don’t want “something” to
55 mean “don’t have a stable tree”. The stable tree provides me with a
56 benefit. If standards have to slip a bit to maintain timeliness, then
57 I’d prefer a stable tree that’s as stable as practical, accepting
58 reality—perhaps where users are able to submit reports of working
59 packages, or where we let platform-agnostic packages be stabilized
60 after one arch has tested, or various of the other suggestions in this
61 thread. Just not no stable tree at all.
62 --
63 Christopher Head


File name MIME type
signature.asc application/pgp-signature


Subject Author
Re: [gentoo-dev] rfc: revisiting our stabilization policy Tom Wijsman <TomWij@g.o>