Adam Williamson wrote:
> It seems like extra work for packagers, but in the end it kinda takes the
> pressure off: you only *have* to ship the important fixes to /updates,
> /backports is optional,
That's already a bad thing, users can no longer expect anything, it depends
on the maintainer being willing to do a backport. Now I know our current
policy isn't any better, but that's why I think we should more strongly
encourage upgrades to stable releases. Yet, in practice, I still think a lot
more stuff gets backported in our updates repository than in those backports
repositories of other distros. Also because the maintainers don't have to
worry about a conservative updates stream at the same time. Having both,
we'd have to fix bugs in the conservative updates AND push backports. Of
course that'd tempt maintainers to just skip the backports step. Whereas our
policy is to prefer resolving issues by pushing new upstream releases (it's
even our default policy for security updates, unlike RHEL which defaults to
backporting), so we just do the backports as stable updates and that way
also resolve the bugs at the same time (including bugs which upstream fixed
and which didn't have a Fedora bug report in the first place, but still
affected Fedora users). Upgrading basically gives us the bugfixes "for free"
(in fact I usually just need to copy the specfile from devel to F-13, F-12
and F-11 and build for all).
> and /backports users are good about knowing that sometimes what they find
> there will be broken or have new bugs or whatever, and tend to know the
> drill about not getting too upset and reporting them to you to be fixed.
That also sucks. With Fedora's KDE updates, users can be sure that they'll
be as regression-free as humanely possible and we do all we can to keep
their updates stable. On the other hand, users of distros using the
backports model just get told "backports are unsupported". In fact their
builds of new KDE releases tend to carry only the same old distro patches as
the old version or even to be entirely vanilla, very little is done to e.g.
backport regression fixes from the branch. And KDE is just the example I'm
most familiar with, I'm pretty sure it's similar with other stuff that gets
updated in our stable updates vs. other distros' backports repositories.
Another big issue is that people will be drawn to selectively picking only
some stuff from the backports repository while staying with the official
updates for other stuff, leading to an untestable combinatorial explosion of
possible update combinations. (Now I know people can also selectively update
from our updates, but if things break, I can just tell them that selective
updates are not supported and that they should run "yum update" and come
back if their problem still happens after that.)
> And they know they can easily fall back to what's in /updates if they find
> /backports to be broken; it gives them an escape route.
That's the only advantage of that model, I'm not sure it's worth the
drawbacks.
Kevin Kofler
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
