1 |
On 04/05/16 02:01 AM, Kent Fredric wrote: |
2 |
> On 4 May 2016 at 16:46, Matt Turner <mattst88@g.o> wrote: |
3 |
>> Having built many stages for an "unstable" arch (mips) has taught me |
4 |
>> one thing: it's awful being unstable-only. There's no end to the |
5 |
>> compilation failures and other such headaches, none of which have |
6 |
>> anything at all to do with the specific architecture. |
7 |
>> |
8 |
>> Short of adding a middle level ("stable, wink wink nudge nudge") where |
9 |
>> things at least compile, I think the current situation is actually |
10 |
>> significantly better than the alternative of dropping them to |
11 |
>> unstable. |
12 |
> |
13 |
> I feel like there needs to be something inbetween, a mechanism where |
14 |
> things can be deemed "tentatively stable", where in they can still be |
15 |
> later destabilized if evidence compels it. |
16 |
> |
17 |
> As it is, stabilization seems one-directional. If critical defects are |
18 |
> found in "stable" releases, they tend not to escalate in the other |
19 |
> direction. |
20 |
> |
21 |
> And I understand why that is, but it doesn't stop me wishing otherwise. |
22 |
> |
23 |
> But instead of adding a rung between stable and unstable ... maybe the |
24 |
> right approach is to add a layer /beneath/ stable : "Long term |
25 |
> stable". |
26 |
> |
27 |
> Where long-term stable is "Known to be good at a deep and thorough |
28 |
> level by people who use the software regularly". |
29 |
> |
30 |
> Long-term stable at this point is not something I'd suggest people set |
31 |
> as their keywords in general, but it would be a thing that would only |
32 |
> be granted to specific packages on a case-by-case basis, and it would |
33 |
> only be encouraged to be used in the sense of |
34 |
> /etc/portage/package.keywords , where mixing long-term stable and |
35 |
> stable would be "supported" ... somehow. |
36 |
> |
37 |
> IDK, there's still a lot wrong with my ideas, but hopefully there's |
38 |
> some ball here to run with. |
39 |
> |
40 |
> |
41 |
|
42 |
|
43 |
Rather than adding a third layer of stability and splitting the |
44 |
userbase even further, how about we just be less shy about dropping |
45 |
stable keywords on packages back to ~arch when we have bugs that can't |
46 |
be resolved quickly? I know this isn't ideal given everyone --sync's |
47 |
at different times and varying intervals, but if a particular ebuild |
48 |
gets stabilized on an arch and is found to really not be ready at |
49 |
least there's a recourse to undo the stabilization and stop -some- |
50 |
users from getting the new version via their -uDN @world updates. |
51 |
|
52 |
What might we need in terms of better PM support, for stable -> ~arch |
53 |
keywording? |