Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)

Kevin Kofler kevin.kofler at chello.at
Sun Mar 14 17:17:13 UTC 2010


Jon Masters wrote:
> If the only reason to choose Fedora over Ubuntu is because Fedora shoves
> out updates at a higher pace into stable releases, then something is
> severely wrong.

Why? It's exactly what's happening out there in the real world you chose to 
ignore, yet I don't see anything wrong with it.

> There are many good reasons to choose either distro. I happen to quite
> like both, for different reasons. Fedora moves new features into rawhide
> at a higher pace,

That alone is not sufficient to be the most up-to-date distribution, which 
is what many of our users choose us for, an aggressive post-release update 
policy is also needed.

In addition, shipping new features often means shipping early versions of 
new software which needs several feature updates to mature. KDE 4.0 would be 
the obvious example, but there were others as well.

> and Ubuntu is something that I could see a newcomer having a lot of
> success with.

So let them get the newcomers and stop worrying about things like:
* our update policies being too "unstable" for newcomers,
* "simplifying" our download page for newcomers by hiding most of our 
options ("Want KDE? Play hide&seek with us! Want 64-bit? Play hide&seek with 
us! Want …")
etc.

> I don't care whether some new hardware gets enabled through an update. I
> would rather that happen in rawhide and the users who can't use the
> hardware in the stable release have to wait an average of 3 months in
> the worst case that there isn't some level of support available now. Few
> other Operating Systems move at that kind of pace anyway.

For those "other Operating Systems", the drivers come in a CD with the 
hardware. In binary-only form and with a EULA attached, but that's what the 
native drivers of those "other Operating Systems" come as as well. We are 
not one of those "other Operating Systems". We need the hardware to work out 
of the box.

And up to 6 months are way too long to wait to get your hardware working, by 
that time they'll have chosen some other distro, maybe one which happened to 
have a release schedule which aligned better with the hardware purchase 
(which is pure accident), and will never care about Fedora again. Quite the 
opposite: They'll always remember it as "that distro that didn't work on my 
computer" and talk bad about it to all their friends.

> I do care that regressions in the kernel, X, or some other subsystem might
> break things that users who are supported are relying on, just to enable
> other stuff. To me, the fear of regressions outweighs any possible other
> benefit.

If something regresses, there's always the old version to rollback to. If 
the hardware is just not supported, there's nothing to fall back to.

> This isn't Enterprise Linux. I don't need a support period covering the
> equivalent of 14 Fedora release cycles, I am fully happy with some
> considerable churn every 6 or 12 months on my desktop or laptop in the
> interest of being up to date with the latest tech, but I am not happy to
> have that churn be on a normal non-upgrade day when I expect my laptop
> to work (and an update just before a meeting to be safe with respect to
> that laptop running a presentation immediately afterward). Somewhat
> shockingly, some people do use Fedora for day to day stuff.

Then do your updates AFTER that presentation, not before. Where's the 
problem?

> Fedora offers a higher rate of new and experimental features. Those
> should be kept in rawhide *where they belong*, for 6 months, until they
> have had some decent testing and are ready to be released. Users are
> users, they are not guinea pigs to be experimented upon.

Many of our feature updates DID go through Rawhide first. They were just 
released on their own schedule, because they're nondisruptive enough to be 
pushed to a stable release and because Fedora's schedule aligns very poorly 
to the upstream schedule. For example, KDE 4.4 got A LOT of testing before 
it was pushed.

        Kevin Kofler



More information about the devel mailing list