Mike McGrath wrote:
> So when Fedora 12 came out, we allowed users 7 months to upgrade because
> the latest version of stuff is too unstable for them. At the same time
> we're also forcing them to upgrade to the latest versions of those
> packages in F-11 anyway? I hope you can at least acknowledge why I'm not
> following the logic here?
Those packages we're upgrading in F11 are not the ones which are causing
their problems with F12. E.g. KDE 4.4 can't possibly be what prevented them
from upgrading to F12 because F12 originally shipped with 4.3. And more in
general, the idea is to push updates IF AND ONLY IF they don't break things,
while leaving the disruptive changes to Rawhide / the next release only.
(For example, we don't enable KMix PulseAudio integration by default because
it makes KMix work significantly differently and some users would not like
losing their hardware controls by default in an update. (That said, in this
case, the feature can be enabled or disabled at runtime, so we ship it, just
disabled by default, it can be enabled manually. That way, we provide the
feature without disrupting anything.))
The point which you don't seem to understand is that there are 2 classes of
upgrades (well, the line may not be perfectly clear-cut, but it's usually
pretty well drawn):
1. upgrades which disrupt, regress or break things. Those can only be pushed
to Rawhide, if at all. (Sometimes it might be better to not push a change
even to Rawhide.)
2. upgrades which do none of the above. Those are what adds value to stable
releases and pushing those is a good thing. It provides value which no other
major distribution is providing, at least not those with numbered releases.
(And completely rolling releases are not a solution because they have no
good way to handle type 1 upgrades, that's also why Rawhide is not suitable
for most users.)
Kevin Kofler
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
