| 1 |
On 05/04/2016 11:41 AM, Ian Stakenvicius wrote: |
| 2 |
> On 04/05/16 02:01 AM, Kent Fredric wrote: |
| 3 |
>> On 4 May 2016 at 16:46, Matt Turner <mattst88@g.o> wrote: |
| 4 |
>>> Having built many stages for an "unstable" arch (mips) has taught me |
| 5 |
>>> one thing: it's awful being unstable-only. There's no end to the |
| 6 |
>>> compilation failures and other such headaches, none of which have |
| 7 |
>>> anything at all to do with the specific architecture. |
| 8 |
>>> |
| 9 |
>>> Short of adding a middle level ("stable, wink wink nudge nudge") where |
| 10 |
>>> things at least compile, I think the current situation is actually |
| 11 |
>>> significantly better than the alternative of dropping them to |
| 12 |
>>> unstable. |
| 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 |
> Rather than adding a third layer of stability and splitting the |
| 43 |
> userbase even further, how about we just be less shy about dropping |
| 44 |
> stable keywords on packages back to ~arch when we have bugs that can't |
| 45 |
> be resolved quickly? I know this isn't ideal given everyone --sync's |
| 46 |
> at different times and varying intervals, but if a particular ebuild |
| 47 |
> gets stabilized on an arch and is found to really not be ready at |
| 48 |
> least there's a recourse to undo the stabilization and stop -some- |
| 49 |
> users from getting the new version via their -uDN @world updates. |
| 50 |
> |
| 51 |
> What might we need in terms of better PM support, for stable -> ~arch |
| 52 |
> keywording? |
| 53 |
> |
| 54 |
> |
| 55 |
+1 |
| 56 |
|
| 57 |
Nice to know that when there is a bug on stable that a world upgrade |
| 58 |
will fix the issue within a reasonable time frame. Even if it means some |
| 59 |
downgrades. |
Archives