Stable Release Updates types proposal

[Al Dunsmuir]

Hello Kevin,

Friday, March 12, 2010, 5:39:33 PM, you wrote:
>> On Fri, 12 Mar 2010 21:18:11 +0100 Simo Sorce wrote:
>> rawhide? F-13 ?

> No.

> This has already been explained several times!

> Rawhide is not the answer. It comes with disruptive changes (and there's no
> real way to avoid this problem, see e.g. my replies to Doug Ledford's "To
> semi-rolling or not to semi-rolling, that is the question..." thread for
> details, but it has also been brought up in other threads), prereleases of
> software which is only expected to be stable at release time, no testing
> repository (so all the breakage gets dumped directly on the Rawhide user)
> etc.

> The upcoming release branch is also not the answer. It is not available at
> all half of the time, and it is feature-frozen, so it doesn't actually get
> the expected feature upgrades (and with a policy like the one you appear to
> defend, it won't get them at all, not even after the release).

>         Kevin Kofler

Maybe   part   of  the  answer  is  that  some  resources  (especially
automation)  need to be dedicated to keep the core critical components
of rawhide from being gratuitously broken and staying that way?

If  these core components were on average in better shape, that should
mean that the other packages would tend to also be in better shape.

That  way,  instead  of  a massive "get rawhide branch working" effort
spike,  some  of that effort could be used on an ongoing basis to keep
the  spike  smaller  -  perhaps even containable, so there is a better
chance that the branch works and the alpha doesn't slip so often or by
so much.

Al
-- 
Best regards,
 Al                            mailto:al.dunsmuir at sympatico.ca