On Sun, 2009-05-10 at 22:58 +0100, John5342 wrote: > updates - Non-breaking updates. Nothing stopping this or any of the > above from being bleeding edge and it should recieve updates to latest > version where possible so long as it doesnt result in breakage or > regressions. This is an essentially nonsensical criterion for something as big as OpenOffice.org and KDE. The likelihood of any versioned change in a codebase that big introducing *some* regression *somewhere* for *somebody* comes very close to 1. The only sensible policies for updates are the traditional "minimum possible change required to fix the specific bug being addressed" (which most distributions follow), or "whatever the hell you like". Trying to codify anything in the middle distribution-wide is essentially impossible, because we package several thousand chunks of code of hugely varying size and importance with utterly different policies as to what a major version means, what a minor version means and so on. To me, this comes back - again - to what I've been thinking about for a while now: what do we want Fedora to be? Who do we want it to be for? If we care about end users - the stereotypical "my aunt", "my grandad", whoever people think of when they think of someone who just doesn't care and wants a computer that works - we need a proper conservative stable update set somewhere. I think Mandriva has the best policy: it has stable releases and a two-tier upgrade repository system. Each stable release has a /updates repository, and a /backports repository. /updates is the traditional "minimum possible change" repository, and is the only update repo enabled by default, so by default you get the traditional conservative, stable update strategy. It is gated through the QA team and then the security team (which is a bit of a historical anomaly, but in practice, works well) who only sign off on updates that comply with the policy. /backports is the "anything you want" repository: maintainers can throw in new packages, new versions, experimental new patches, pretty much anything they like, without oversight (maintainers literally just run a single submit command and it goes straight out to the public repos). If you want new versions of stuff for a stable release, you use /backports. 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), 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. If we don't care about end users who want a stable computing platform and we want Fedora to be principally a platform for development / experimentation, I think a single "whatever the hell you like" update repository works best. The two-tier system that's good for end users would also work, but would be overly complicated for achieving the desired result (and maintainers likely wouldn't see the value in following it). We could certainly care about 'quality' in the update repository in terms of whether the packages are valid, have broken dependencies etc, but we wouldn't necessarily care about regressions / breakages in the code they contain. But, yet again, it's a question that can't be answered until we know what exactly Fedora is supposed to be, and for whose benefit. Even if we come up with a consistent and coherent policy it likely won't work until that question is properly answered and agreed upon. -- 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
