Gentoo Archives: gentoo-dev

From: Alan McKinnon <alan.mckinnon@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] rfc: stabilization policies
Date: Wed, 21 Aug 2013 06:26:15
Message-Id: 52145CAA.4070702@gmail.com
1 On 20/08/2013 22:25, Tom Wijsman wrote:
2 > On Tue, 20 Aug 2013 22:00:52 +0200
3 > Alan McKinnon <alan.mckinnon@×××××.com> wrote:
4 >
5 >> As a long time user and citizen of -user I can tell you what the
6 >> general feeling of arch vs ~arch there is:
7 >
8 > Thanks for jumping into the discussion.
9 >
10 >> arch has plenty old stuff in it
11 >
12 > Yes, it keeps me from using it; I would have to unmask too much...
13 >
14 >> ~arch is plenty good enough for everything except very mission
15 >> critical stuff
16 >>
17 >> ~arch does not break every other day, and breakage is actually
18 >> surprisingly rare. And, it's usually confined to
19 >> openrc/udev/systemd/baselayout and other critical packages where one
20 >> just knows upfront anyway that danger may lurk ahead.
21 >>
22 >> Some folks like me sync daily and accept that I deal with occasional
23 >> breakage maybe once a month. Usually I just mask an offending package
24 >> and move on. Others wait a few days and if no reported bugs, then
25 >> emerge it.
26 >
27 > This really sounds like what would be the description of stable; I
28 > mean, for mission critical stuff someone would plan out a migration and
29 > "test" the upgrade prior to applying it to the server. For the rest,
30 > except for maybe that critical packages shouldn't break; an issue once
31 > a month is something that slips through, eg. see the stable bugs...
32 >
33 >> I get the sense that hard masked and -9999 is the new testing,
34 >
35 > Actually, hard masked is usually something that is really broken; while
36 > there are some things masked for some other reasons, you can't really
37 > regard it as testing. But yeah, as for -9999, it could be considered
38 > testing; although it is often broken, because of broken patches, ...
39 >
40 >> I also get the sense that arch progresses too slowly for many people.
41 >
42 > +1 that's one of the points that came up on IRC; 30 days and more
43 > being too long, because not everyone follows up with that time
44 > schedule (we are people, not cronjobs), it even gets a bit longer...
45 >
46 >> How long did we wait for MySQL-5.5 to reach arch? Folk wanted that
47 >> one in stable reasonably early and mixing arch/~arch is very very bad
48 >> in real life. Hence the recommendation to switch to ~arch, and it
49 >> usually works out just fine.
50 >
51 > Yes, but we don't want to end up having everyone having mixed trees or
52 > be on ~arch; if we do, stabilization is going to become a wasted effort.
53
54 Perhaps the area to be clarified is "what is the intended risk profile
55 for arch and ~arch?"
56
57 stable and unstable mean very different things to different people, they
58 are quite overloaded terms, so a proper definition is in order. Then
59 users can also accurately just what they are going to get in arch as
60 well as the intended level of stability.
61
62 We already have a good beginning with the usual description of ~arch as
63 "works pretty much OK most of the time but new ebuilds go in here first
64 so expect some breakage sometimes". Let's express that in terms of risk.
65
66 Something else we should also keep in mind - binary distros often
67 recommend that autoupdates be enabled. If people do this it changes the
68 game play as they really don't know what is coming down the wire at all.
69 Gentoo is different - nothing changes until you sync and emerge world
70 and this really does require that the sysadmin eyeballs the output. This
71 removes a lot of the risk from the devs (you can't really know what my
72 USE will do on my end so I must assume some responsibility for my
73 choices). I do believe this gives the devs a lot of wiggle room to get
74 things into arch quicker without having to test and verify every little
75 thing.
76
77 --
78 Alan McKinnon
79 alan.mckinnon@×××××.com