Adam Williamson wrote:
> See my original post. I don't accept that you can safely have an updates
> policy which professes to provide a 'stable' update repository while
> allowing tomfoolery like upgrading KDE wholesale. It's just not
> practically possible, and our current update repositories prove that
> quite nicely. The only consistently practicable update policies are
> "minimal necessary changes" and "do whatever you like". If you run a
> stable Fedora release and install all official updates, you will get
> significant changes in basic functionality and, in all likelihood,
> visible regressions. Our current updates policy does not provide a
> stable experience along the lines of what you get from distributions
> which follow the industry standard "minimal possible change" policy.
I don't think I can agree with this. I think equating "version upgrades ==
unstable" is something which just doesn't make sense. Version upgrades can
be categorized into 4 classes (note that the numbers are just examples,
they are not authoritative, as some projects use weird versioning schemes
or make strange decisions what to include in bugfix releases):
1. the "single fix only" release, often signaled by prepending "a" or an
extra ".1" to the version number – those are almost always completely safe,
they aren't any more dangerous than just applying the patch to the RPM in
any case (which we usually want to do anyway because those "a"/".1" fixes
are often security fixes or "brown paper bag" fixes).
2. the bugfix release, e.g. KDE a.b.n -> a.b.n+1 or the kernel 2.6.a.n
stable branches – those are almost always appropriate for stable updates,
after 1 or 2 weeks of testing. Fixing bugs is what updates are for! And
those releases are designed to do nothing else. Now there are cases where
such releases introduce regressions (e.g. Qt 4.5.1 has some regressions
from 4.5.0), so they need to be handled with care, but in general it's a
good idea to push these! I don't see how an update from e.g. KDE 4.1.2 to
4.1.3 is going to make "average users" unhappy, all it does it fix bugs and
update translations!
3. the minor feature release, e.g. KDE a.n -> a.n+1 or kernel 2.6.n ->
2.6.n+1 – those need to be handled with care as they can introduce
breakage. But those normally (of course it depends on upstream!) don't come
with major functionality change which breaks everything: for example, Qt
and kdelibs maintain backwards API/ABI compatibility, the kernel often has
config options which use the old code rather than the new one for major
changes like libata and those options are used in the stable updates, etc.
Of course those updates should stay in testing for at least 2 weeks to
track down and fix regressions and in some cases pushing the update may be
a bad idea altogether. This kind of updates really needs to be evaluated by
the maintainer of the individual component. (But I do personally think that
in most cases those are OK for a stable update.)
4. the major feature release or rewrite, e.g. KDE 3 -> 4, Amarok 1 -> 2
etc. – those come with known feature and stability/reliability regressions
make absolutely no sense to push as a stable update to a released distro!
(Of course there are some project releasing "new major versions" which are
not of that type, but in that case they should be handled like "minor
feature releases" above. But e.g. Amarok 2 is most definitely a major
feature release with significant code rewriting.)
I think a "backports" release mixing 1, 2, 3 and 4 is completely useless
(how's that different from Rawhide?), whereas 1 and 2, and 3 when carefully
done can lead to usable "stable but current" updates. (I could probably
live with just 1 and 2, but I think it would be worse than the current
system and there would need to be some exceptions, e.g. I think leaving F9
with KDE 4.0 would have been a major disservice to our users.)
Thankfully, "1 and 2, and 3 when carefully done" is mostly how Fedora's
current updates work. The complaints are about maintainers who refuse to
push type 3 or even type 2 updates altogether, or in some cases about
maintainers who push type 4 updates or badly-tested/untested type 3
updates.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
