On Wednesday 03 March 2010 15:16:05 Chris Adams wrote:
Once upon a time, Thomas Janssen <thomasj(a)fedoraproject.org>
said:
> On Wed, Mar 3, 2010 at 9:03 AM, Jon Masters <jonathan(a)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(a)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/