Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)

Peter Hutterer peter.hutterer at
Fri Mar 12 00:56:07 UTC 2010

On Fri, Mar 12, 2010 at 01:26:26AM +0100, Kevin Kofler wrote:
> Chris Adams wrote:
> > Developers can't always get what they want.  Just because Fedora updates
> > to upstream's release-of-the-day doesn't mean Ubuntu, SuSE, etc. have
> > updated (so hopefully upstream is still paying attention to older
> > releases).
> It is (especially for leaf packages) much more likely they're going to say 
> one or more of:
> * "screw you, use a sane distro" (and we lose the user),
> * "just build our tarball from source" (with the result that the user ends 
> up with an unpackaged mess in /usr/local which grows like mold),
> * "screw the distro packages, use ours" (and this leads us to the "third-
> party package chaos" problem, which is characterized by low-quality 
> packages, dependency hell, inter-repository compatibility issues etc.).
> > Most reasonable upstreams I have worked with fully understand that not
> > everybody is running yesterday's release and will work with you if you
> > find a problem with an older release.  If an upstream can't handle that,
> > I would say that is the upstream's problem, not Fedora's.
> Upstream cannot go back in time and magically fix a bug in an old release. 
> The bug is often already fixed in the current release, so the solution is 
> for us to package the current release. And no, backporting fixes is often 
> not practical.

I know that backporting fixes is often not practical, especially if there is
a lot of code churn upstream. How often this is the case depends on the
project of course. Do you have any cost estimates on that though? (honest
question, I'm not involved with KDE so I can't even guess)

As in, on average what are the costs of leaving a bug in vs. the cost of
updating to a new release. I noticed that there's a number of bugs that only
affect a subset of users that (often) can work around the issue. So the cost
- while high to a particular user - may be quite limited.
Updating to a new release will affect _every_ user and given that software
is imperfect it's likely that existing bugs will just be replaced by new,
different bugs. So on the one side you have the cost of having known bugs,
on the other side you have the benefit of fixing (some) bugs but the cost of
new bugs and a potential change in the user experience. Which one is higher
than the other one?


More information about the devel mailing list