Gentoo Archives: gentoo-dev

From: Rich Freeman <rich0@g.o>
To: gentoo-dev <gentoo-dev@l.g.o>
Cc: William Hubbs <williamh@g.o>
Subject: Re: [gentoo-dev] rfc: revisiting our stabilization policy
Date: Wed, 15 Jan 2014 12:51:59
In Reply to: Re: [gentoo-dev] rfc: revisiting our stabilization policy by "Michał Górny"
1 On Wed, Jan 15, 2014 at 4:54 AM, Michał Górny <mgorny@g.o> wrote:
2 >
3 > 2) has to add package.accept_keywords entry for the package. Which
4 > means turning a pure stable system into an unsupported mixed-keyword
5 > system.
7 As opposed to an unsupported pure stable system or an unsupported pure
8 unstable system? I doubt anybody runs a pure stable system, and if
9 they do I doubt their experience is much different from those who run
10 mixed keywords.
12 Of course, having random system packages drop stable keywords from
13 time to time isn't going to help anything in that department.
15 Obviously maintainers should keep stable system packages around as
16 long as they can. However, there needs to be some way to deal with
17 cases where their stabilization gets held up on a major arch. If we
18 don't have the manpower to stabilize newer versions, what makes
19 anybody think that maintainers have the manpower to "support" ancient
20 versions?
22 The have our cake and eat it too solution is to obtain more manpower.
23 That should be done without question, but for whatever reason it never
24 actually happens, so we need to think about what the alternative is.
25 If talking about it scares more people into volunteering so that it
26 isn't necessary all the better...
28 Given constrained manpower the options basically are some variation on:
29 1. Status quo - for some packages stable gets REALLY old, and likely
30 has problems that maintainers ignore. You can't force somebody to
31 maintain something any more than you can force somebody to test
32 something.
34 2. We become more liberal with stabilizing newer versions. Lots of
35 variations on this, but the bottom line is that packages get
36 stabilized that would otherwise not be.
38 3. We drop stable keywords on packages. Lots of variations on this
39 as well, but the result is mixed-arch systems or dropping stable for
40 the whole arch.
42 I don't think #1 is really the answer - it just results in
43 less-visible problems and a stable that is probably works worse than
44 either #2 or #3 would yield.
46 #2 has the advantage that it gives us more control over what gets
47 installed on stable systems and you don't end up with mixed keywords.
48 The downside to #2 is that the user doesn't have as much visibility
49 into which packages are "really" stable. Maybe an in-between quality
50 tier would help (if you're going to run a mixed keyword system, at
51 least use this version).
53 #3 has the advantage that it makes the problem directly visible to the
54 user. However, the solution ends up being entirely user-discretion.
55 Some users end up on ~arch for life, others do it version-by-version
56 in which case they end up on various versions. Personally I run
57 stable and when I need to run unstable on a package I tend to use
58 <cat/foo-major+1 syntax so that I'm tracking unstable until the next
59 major version and then I get a chance to revisit the decision -
60 usually stable catches up by then.
62 The only "nice" solution is more manpower. I'd like a pony to go with
63 that as well...
65 Rich


Subject Author
[gentoo-dev] Re: rfc: revisiting our stabilization policy Duncan <1i5t5.duncan@×××.net>