[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: OpenOffice 3.1
- From: Adam Williamson <awilliam redhat com>
- To: Development discussions related to Fedora <fedora-devel-list redhat com>
- Subject: Re: OpenOffice 3.1
- Date: Mon, 11 May 2009 13:14:25 -0700
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
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.
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
[Date Prev][Date Next] [Thread Prev][Thread Next]