[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Reminder: ALLARCHES
From:       Damien LEVAC <damien.levac () gmail ! com>
Date:       2016-05-04 15:45:25
Message-ID: 572A1915.3010504 () gmail ! com
[Download RAW message or body]



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

Nice to know that when there is a bug on stable that a world upgrade 
will fix the issue within a reasonable time frame. Even if it means some 
downgrades.

[prev in list] [next in list] [prev in thread] [next in thread]