Worthless updates

[Jaroslav Reznik]

On Wednesday 03 March 2010 15:16:05 Chris Adams wrote:
> Once upon a time, Thomas Janssen <thomasj at fedoraproject.org> said:
> > On Wed, Mar 3, 2010 at 9:03 AM, Jon Masters <jonathan at jonmasters.org> 
wrote:
> > > My own personal opinion is that stable updates should only fix serious
> > > issues, or security problems. Fedora has such a short lifetime as it
> > > is, I really can't see the value in pushing features to F11 when it
> > > will die soon. I think it's far better to leave the churn in rawhide.
> > 
> > Rawhide for the masses to stay uptodate? Dont support F-11 well
> > because it will die "soon"?
> 
> So to you fixing major bugs and security problems == not supported?  I
> don't think so.
> 
> > Why isn't it up to the maintainer to provide latest versions even for
> > "die soon" versions of Fedora if he want to do it?
> 
> Because a distribution is about more than being a collection of
> packages!
> 
> Some packagers are turning Fedora into a rolling-update package
> collection instead of a coherent distribution.  Remeber the days of a
> fairly small package set in RHL, when people dumped whatever they found
> on rpmfind.net on their system?  They'd then ask a question on a list
> about RHL version foo, and you just about had to get an "rpm -qai" to
> figure out what was going on.
> 
> Right now, if somebody asks a question about F12 Firefox, you have a
> reasonable expectation that it is 3.5.x.  If they ask about F12 KDE, who
> knows.

It's very easy - latest KDE stable release.

> A distribution should have a coherent set of rules about what makes up
> the distribution.  Fedora has lots of rules and guidelines, but really
> nothing about what packagers should do about updates.  Without that,
> Fedora is turning into chaos.
> 
> What we have right now is the wild west; what we need is update
> sheriffs.
> 
> On my mirror, updates/12 is approaching the size of releases/12/Fedora
> (which includes CD and DVD ISOs!), and that is in under 4 months.  That
> is an insane amount of churn.  Users do complain about it, when they
> install from a release DVD a few months after release and then spend
> hours downloading updates.
> 
> > If someone think he doesn't need an particular update, dont update it.
> > I never had a gun pointing to my head telling me i HAVE to update
> > everything.
> 
> Because users can't be expected to know what needs updating and what
> does not.
> 
> If Fedora is going to be a rolling update package collection (despite
> what Kevin tries to claim about some mythical "semi-rolling", that's
> what we are getting in some quarters), then stop the releases every 6
> months.  There's no point; put a little more effort into the respins
> instead and release those every 4-6 months as point releases.  Have an
> annual roll-up release and then keep rolling.
> 
> If instead Fedora is going to try to be a stable, coherent distribution,
> then only bug (including security) fix and probably hardware support
> (e.g. kernel, xorg) updates (and any necessary dependencies) should be
> pushed.  Minor version updates are okay, but major version updates (and
> ABI breakage) are to be avoided unless absolutely necessary.

But that's the problem - this world is not ideal, especially open source 
world. The upstream development does not freeze with Fedora release - believe 
me - it's not fun to for example backport security bugfixes for web browser 
(WebKit and KHTML in my case). 
Same - what's mirror version update? Every single open source app has different 
policy (they usually don't have policy). Even big project like Qt & KDE are 
breaking their policies sometimes - for example ABI breakage - mayor release 
should not break ABI and we saw few minor releases to do it... Can we hang 
upstream? And again - what's mayor, what's minor? For example current KDE 
y.x.z - y is mayor, x is minor, z is bugfix... In some projects even z bugfix 
could be minor, for other project... So any rules like this are insane! What's 
the sane resolution? Only one rule - to ensure that update meets high level of 
quality. 

Jaroslav
-- 
Jaroslav Řezník <jreznik at redhat.com>
Software Engineer - Base Operating Systems Brno

Office: +420 532 294 275
Mobile: +420 731 455 332
Red Hat, Inc.                               http://cz.redhat.com/