On Wednesday 03 March 2010 15:16:05 Chris Adams wrote: > Once upon a time, Thomas Janssen <thomasj@xxxxxxxxxxxxxxxxx> said: > > On Wed, Mar 3, 2010 at 9:03 AM, Jon Masters <jonathan@xxxxxxxxxxxxxx> 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@xxxxxxxxxx> Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
