OpenOffice 3.1

Adam Williamson awilliam at redhat.com
Mon May 11 18:02:48 UTC 2009


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




More information about the devel mailing list