Stable Release Updates types proposal
Al Dunsmuir
al.dunsmuir at sympatico.ca
Fri Mar 12 23:08:07 UTC 2010
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
More information about the devel
mailing list