On 04/05/16 02:01 AM, Kent Fredric wrote:
> On 4 May 2016 at 16:46, Matt Turner <matts...@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?


Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to