On Mon, 2009-05-11 at 21:47 +0200, Kevin Kofler wrote: > Adam Williamson wrote: > > I know this is a good system because I was around for the previous > > system (a messy compromise rather like the current Fedora system), which > > everyone hated - developers didn't know what to ship where, users didn't > > know what to expect. The current system is great: developers understand > > it and have the flexibility to ship the type of updates they want (they > > can choose to ignore /backports entirely and only ship stable updates, > > or they can use it extensively and provide, say, a whole new version of > > KDE), > > So there's still the same inconsistency we're having in Fedora too (and > having "backports" not enabled by default also encourages laziness, i.e. > ignoring it entirely; IMHO disabling "backports" by default is also a > disservice to users, who don't get the latest bug fixes). The fundamental point here is that most end users want stable systems. So you have to provide a set of stable updates and *only* stable updates. Some distros do only this - Ubuntu, for e.g. - and leave the more adventurous stuff to messy alternatives (PPAs, the sparsely used semi-official 'backports' repository for Ubuntu, random repositories set up by random people on random pages somewhere). How MDV got to where it is is basically that it started by only producing stable updates, then realized there was enough of a demand for adventurous updates that an outlet for those should be provided somehow. I think the two-tier, adventurous updates disabled by default setup is the best compromise anyone's come up with yet, *for the case where a stable update set is considered important* (i.e. we actually care about Aunt Flo). I can see your theoretical point about backports being ignored, but in practice - for whatever reason - it isn't the case. the repository is heavily used by both maintainers and users. > > users understand it and have the flexibility to choose exactly > > what type of updates they want (/updates only for a quiet life, specific > > packages from /backports if you just need some particular new feature, > > or everything from /backports if you like surprises). Significantly, > > there have been exactly no major arguments like this present one ever > > since the system was changed, whereas bitching and arguing over the > > previous system was frequent on both the 'user' and 'developer' sides. > > A big problem with having separate "updates" and "backports" is that we'd > have twice as many branches to maintain, "updates" for every Fedora release > with only the stuff which is arbitrarily defined to be acceptable there > and "backports" with the current upstream releases. KDE SIG and several > other maintainers or teams are already overworked, doubling our workload > (for everything except Rawhide, but if Ralf's "rawhide-testing" idea gets > implemented, we might end up with doubled workload there too!) isn't going > to help at all! Yep, this is the biggest concrete objection. My answer is that if we care about Aunt Flo, suck it up, princess, because it's the only viable system. :) Any "flexible" update system is going to screw Aunt Flo (or Joe Stable-Set-Of-Systems Sysadmin, or anyone who needs the proper stable update set) over at some point. If we don't care about Aunt Flo - or any of the other users who need a stable update set - see my original post, where I said we can then just have the single 'whatever the hell you like' update repo. It's not a rhetorical trick, it's a genuine fundamental point for discussion: I'd be perfectly happy if we, once and for all, declared that we really don't give a shit about 'stable' use cases; if you want those, use some other distro. I'm fine with that. But it's a decision that needs to be taken, because right now we have confusion, lack of focus and messy compromises in a whole bunch of areas caused by the lack of a clear answer to that question. > IMHO "backports" are a half-baked workaround for inflexible upgrading > policies and generate unneccessary maintainer workload and a poor user > experience (especially if they're labeled "unsupported" as e.g. Ubuntu is > doing, I'm not sure how Mandriva handles it). They're officially unsupported, because MDV is a commercial distro with a strict definition of what 'supported' means (MDV commits to fix serious bugs and security issues in packages labelled as 'supported') and it is insane to make that commitment for backport packages. But in practice, most maintainers accept and fix bug reports in backport packages much the same way they do for others. The Ubuntu backport repositories are an excellent example of how not to do it - they have crappy user and maintainer buy-in and most 'backports' are in practice done through PPAs, official or unofficial. Which stinks, but we're not in a 'why Ubuntu stinks' thread here :) > The only kind of "backports" repository I could envision is for packages > which DON'T make sense to ship as stable updates, e.g. major bumps like > Amarok 1->2 in F9, i.e. the kind of stuff we're shipping in kde-redhat > unstable and other similar repositories. But it should not be the norm for > all new versions (and mixing minor bumps like KDE 4.0->4.1->4.2 with major > changes like Amarok 1->2 in a single repository would also significantly > degrade the user experience – this is another problem I've seen > with "backports" repositories, they encourage throwing in risky or even > unstable (e.g. KOffice 2) updates together with riskless ones like even > bugfix releases of KDE (e.g. 4.1.2->4.1.3) in the same repository). See my original post. I don't accept that you can safely have an updates policy which professes to provide a 'stable' update repository while allowing tomfoolery like upgrading KDE wholesale. It's just not practically possible, and our current update repositories prove that quite nicely. The only consistently practicable update policies are "minimal necessary changes" and "do whatever you like". If you run a stable Fedora release and install all official updates, you will get significant changes in basic functionality and, in all likelihood, visible regressions. Our current updates policy does not provide a stable experience along the lines of what you get from distributions which follow the industry standard "minimal possible change" policy. As I said a few times, this isn't inherently a bad thing. If we're clear that this is what we *want*, and we communicate that properly, it's fine. But I don't think you can pretend to provide a 'stable' distribution while allowing the shipping of updates in the way we currently do. We need clarity and focus here. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
