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 |