Gentoo Archives: gentoo-dev

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: rfc: revisiting our stabilization policy
Date: Wed, 15 Jan 2014 21:42:42
Message-Id: pan$1b393$7374d71d$d6fbf6c7$462161b9@cox.net
In Reply to: Re: [gentoo-dev] rfc: revisiting our stabilization policy by Rich Freeman
1 Rich Freeman posted on Wed, 15 Jan 2014 07:51:49 -0500 as excerpted:
2
3 > Given constrained manpower the options basically are some variation on:
4
5 > 1. Status quo - for some packages stable gets REALLY old, and likely has
6 > problems that maintainers ignore. You can't force somebody to maintain
7 > something any more than you can force somebody to test something.
8 >
9 > 2. We become more liberal with stabilizing newer versions. Lots of
10 > variations on this, but the bottom line is that packages get stabilized
11 > that would otherwise not be.
12 >
13 > 3. We drop stable keywords on packages. Lots of variations on this as
14 > well, but the result is mixed-arch systems or dropping stable for the
15 > whole arch.
16 >
17 > I don't think #1 is really the answer - it just results in less-visible
18 > problems and a stable that is probably works worse than either #2 or #3
19 > would yield.
20 >
21 > #2 has the advantage that it gives us more control over what gets
22 > installed on stable systems and you don't end up with mixed keywords.
23 > The downside to #2 is that the user doesn't have as much visibility into
24 > which packages are "really" stable. Maybe an in-between quality tier
25 > would help (if you're going to run a mixed keyword system, at least use
26 > this version).
27
28 What about a third "target-stable" keyword? Either arch-teams or package-
29 maintainers (with maintainers getting priority in case of differing
30 viewpoints, just as arch-teams already have priority over full-stable)
31 could set this, and it would let users who wanted to be "almost stable
32 but hasn't gotten thru all the hoops just yet" arch-testers do just that,
33 see and test almost-stable packages.
34
35 An open stabilization bug would be required for any target-stable
36 package, and only one target-stable per-slot per-arch would be allowed --
37 if there's already a target-stable in that slot for that arch, it would
38 need to be removed and either that package fully stabilized or the new
39 one substituted in the target-stable slot.
40
41 * Note however that different archs could however have different target-
42 stable packages within a slot. This would allow a maintainer to set a
43 minimal version target-stable keyword for lagging archs, while setting a
44 preferred version target-stable keyword for current archs.
45
46 A maintainer facing lagging archs could then set target-stable
47 appropriately, and could re-assign any bugs on the old-stable version to
48 the arch in question, with comment boilerplate to the effect that the
49 arch is lagging and hasn't updated stable, so they get to deal with bugs
50 for their ancient-stable version.
51
52 A variant on the theme would be to split the current stable keyword in
53 half, arch-stable and maintainer stable. Any package version keyworded
54 for both would be considered fully stable, but the two halves would then
55 be fully independent, no longer interlocked, and for half-stable packages
56 bugs would be assigned to the stable side with the other side CCed. In
57 this variant, there'd be no limit on the number of package versions that
58 could be half-stabled by either half, just as there can now be multiple
59 stable-keyworded versions, and for that matter, multiple testing versions
60 as well.
61
62 > #3 has the advantage that it makes the problem directly visible to the
63 > user. However, the solution ends up being entirely user-discretion.
64
65 Either target-stable keyword variant above would be directly visible to
66 the end user as well, and of course they could choose full-stable or half-
67 stable on either side as they wished.
68
69 > Some users end up on ~arch for life, others do it version-by-version in
70 > which case they end up on various versions. Personally I run stable and
71 > when I need to run unstable on a package I tend to use <cat/foo-major+1
72 > syntax so that I'm tracking unstable until the next major version and
73 > then I get a chance to revisit the decision - usually stable catches
74 > up by then.
75
76 Interesting. Nominally I do ~arch as for me stab?le== , but I do more or
77 less the same thing at the overlay-~arch/unkeyworded/masked/live-9999
78 level.
79
80 For my kde packages, for example, I run the overlay and normally
81 package.keyword/package.unmask 4.y.9999 as soon as it's available in the
82 kde overlay (I have scripts that do git log --color --stat --graph
83 $branch ORIG_HEAD.. on the overlays, and routinely run them after
84 syncing so I know what's going on). But since upstream kde doesn't split
85 a branch until the rcs and thus those branches and the kde overlay
86 packages based on them don't appear for the betas, I have to switch to
87 -9999 during the kde betas, and "downgrade" back to 4.y.9999 when
88 upstream branches and the 4.y.9999 ebuilds appear. I suppose one of
89 these days I'll setup kde-frameworks and be doing about the same for it,
90 too...
91
92 What's nice is that for kde 4.12.9999 for example, when gentoo/kde was
93 still sorting out the masking/dependencies issues in the overlay due to
94 plasma/workspace being locked to 4.11.x, I was able to grab the 4.11.9999
95 unmask files from the overlay, do a global search and replace 4.12.9999
96 in place of 4.11.9999 but keeping the 4.11.9999 for workspace packages,
97 set a few KDE_OVERRIDE_MINIMAL=4.11 via package.env, and go to town with
98 4.12.9999 before gentoo/kde had finished sorting out the masking and
99 dependency issues themselves. =:^)
100
101 Of course for kde there's the -4.x.9999 versions to use. For openrc,
102 etc, there's not. There it's -9999 or ~arch, and for openrc in
103 particular I use -9999 because the ~arch ebuild changelogs simply aren't
104 detailed enough and it's too difficult to track down the bugs when they
105 inevitably appear. Git log and if the commit log is interesting enough,
106 git show <id>, is far *FAR* better! =:^)
107
108 Unfortunately, while it might have been useful for devs, git-r3 has sure
109 been a headache for users trying to follow upstream development with git
110 log ORIG_HEAD.. There's workarounds, but they're a lot more hassle with
111 git-r3 than git2 was. =:^(
112
113 --
114 Duncan - List replies preferred. No HTML msgs.
115 "Every nonfree program has a lord, a master --
116 and if you use the program, he is your master." Richard Stallman