Stable Release Updates types proposal

[Simo Sorce]

On Fri, 12 Mar 2010 23:39:33 +0100
Kevin Kofler <kevin.kofler at chello.at> wrote:

> Simo Sorce wrote:
> 
> > On Fri, 12 Mar 2010 21:18:11 +0100
> > Kevin Kofler <kevin.kofler at chello.at> wrote:
> > 
> >> The problem is, if all the
> >> distributions optimize for people with low bandwidth, then what
> >> should people like me who have higher bandwidths and would like to
> >> use their bandwidth to get current software use?
> > 
> > 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).

I seriously think you have a problem understanding the difference
between development and release and what is the purpose of a release.

I understand and wholly reject your point, and I don't think you have
any data to show most of the user that choose to use a release over
rawhide want the kind of rolling release you want.

As far as I can see all you want a slightly-stabler-rawhide, that's not
what a release is.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York