Adam Williamson wrote:
> I know this is a good system because I was around for the previous
> system (a messy compromise rather like the current Fedora system), which
> everyone hated - developers didn't know what to ship where, users didn't
> know what to expect. The current system is great: developers understand
> it and have the flexibility to ship the type of updates they want (they
> can choose to ignore /backports entirely and only ship stable updates,
> or they can use it extensively and provide, say, a whole new version of
> KDE),
So there's still the same inconsistency we're having in Fedora too (and
having "backports" not enabled by default also encourages laziness, i.e.
ignoring it entirely; IMHO disabling "backports" by default is also a
disservice to users, who don't get the latest bug fixes).
> users understand it and have the flexibility to choose exactly
> what type of updates they want (/updates only for a quiet life, specific
> packages from /backports if you just need some particular new feature,
> or everything from /backports if you like surprises). Significantly,
> there have been exactly no major arguments like this present one ever
> since the system was changed, whereas bitching and arguing over the
> previous system was frequent on both the 'user' and 'developer' sides.
A big problem with having separate "updates" and "backports" is that we'd
have twice as many branches to maintain, "updates" for every Fedora release
with only the stuff which is arbitrarily defined to be acceptable there
and "backports" with the current upstream releases. KDE SIG and several
other maintainers or teams are already overworked, doubling our workload
(for everything except Rawhide, but if Ralf's "rawhide-testing" idea gets
implemented, we might end up with doubled workload there too!) isn't going
to help at all!
IMHO "backports" are a half-baked workaround for inflexible upgrading
policies and generate unneccessary maintainer workload and a poor user
experience (especially if they're labeled "unsupported" as e.g. Ubuntu is
doing, I'm not sure how Mandriva handles it).
The only kind of "backports" repository I could envision is for packages
which DON'T make sense to ship as stable updates, e.g. major bumps like
Amarok 1->2 in F9, i.e. the kind of stuff we're shipping in kde-redhat
unstable and other similar repositories. But it should not be the norm for
all new versions (and mixing minor bumps like KDE 4.0->4.1->4.2 with major
changes like Amarok 1->2 in a single repository would also significantly
degrade the user experience – this is another problem I've seen
with "backports" repositories, they encourage throwing in risky or even
unstable (e.g. KOffice 2) updates together with riskless ones like even
bugfix releases of KDE (e.g. 4.1.2->4.1.3) in the same repository).
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
