Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

Simo Sorce simo at redhat.com
Fri Nov 2 22:39:29 UTC 2012


On Fri, 2012-11-02 at 13:22 -0700, Adam Williamson wrote:
> On Fri, 2012-11-02 at 21:07 +0100, drago01 wrote:
> > Well your point basically is "we can't/don't ship anything that is
> > stable so we should give up on that."
> 
> More or less, yes.
> 
> > I disagree with that. Fedora releases had some small regression
> > introduced via updates from time but is is *very* usable as a stable
> > operating system.
> 
> I disagree. It's usable by the kind of people who use Fedora. Who like
> shiny cutting-edge stuff and don't mind dealing with wonkiness
> constantly. I wouldn't dream of putting any regular person on a Fedora
> install, quite frankly.

I do not know in what dreamland you live.

My wife has been running on Fedora since forever, and except some pain
points when we do an upgrade (usually every 2 release) all works just
fine.

If you are advocating for making fedora completely unusable please let
me know in advance so I can start doing my Red Hat work on some other
Linux distro ... I am sure you can read the irony ...


>  It's easy to get into a perspective bubble where
> Fedora looks normal, but it isn't. It is not a stable general-purpose
> operating system and it's absurd to represent it as such. I wouldn't put
> Fedora 17 on my uncle Bob's computer (I don't have an uncle Bob, this is
> just your hackneyed old 'regular person' example) and say 'there's your
> computer'. How many of us would? Even if you get a good Fedora release
> and don't hit problems with updates - which we don't do a _bad_ job of
> these days, admittedly - our releases really aren't quality general
> purpose OSes (we let all kinds of weirdnesses go into our releases which
> a serious user-facing OS would never let go), and after 12 months, you
> have to do an upgrade, which has about a 50/50 chance of exploding,
> let's face it. That's not a convincing stable general purpose operating
> system.
> 
> It's telling that when you meet 'normal people' who are running Fedora,
> they're usually using Fedora N-5, which hasn't had security updates for
> a year and a half. That's how 'normal people' use their computers - they
> don't upgrade every year and find it _fun_ to fix the upgrade process
> when it explodes. I don't think we're serving the (few) 'normal people'
> who run Fedora in this fashion very well, frankly. They'd probably be
> better off with something else.

No normal people run on N-1/N-2 and feel the pain points when they
switch to (a month or 2 old) N once N-2 goes out

> I realize my point of view here is somewhat radical, but you need the
> lunatic fringe around to keep people on their toes, I've always
> thought. ;)

I understand you surfing hyperbole here, but keep in mind that no users
means no developers.
Yes some people like to play with all cutting edge, but most people want
to "use" their distro too.

If it is too painful to stabilize every 6 months, may be we should
change to a rolling release for development, and cut stables only once a
year, to be maintained for 1 year only, I would totally love something
like that as long as the development version is more something like
debian testing/experimental than our current rawhide.

> > Compare it to "always cutting edge" like rawhide ... you can't get any
> > work done with that. It keeps breaking almost every second day.
> 
> Well, that's why I said two streams. One would be what Rawhide is now
> and the other would be pretty much branched/stable level.

rawhide would need to get a little bit more stable to be usable even by
developers in this scheme, doesn't need to be perfect but you can;t have
upgrades that break booting for most people (corner cases always exist
it's development). Currently there is ton of stuff that doesn't even
build until late in the release cycle.

>  On a broad
> conceptual level - there's several ways of doing this, of course. But my
> basic point is that the three stream idea works for a project like
> Debian, which has a conservative approach to everything and is able,
> over a very long timeframe, to produce something that actually *is* a
> stable operating system. It's not appropriate to a project like Fedora,
> which really isn't doing that. How often have we said we don't have the
> people interested in doing LTS releases, for instance? That's the kind
> of work you need to maintain a true 'stable' tier in a three-tier
> system. It's boring maintenance of long-dead code, and that's not
> generally what Fedora people are interested in. How many maintainers
> right now are doing a convincing job of maintaining F16? How many people
> are testing the updates? How many Fedora packagers wake up in the
> morning and think 'hey, what I really want to do today is carefully test
> and backport specific fixes to the F16 branches of my packages'?

Yes this is too much, but we *do* get updates for critical issues, and
not necessarily in form of a rebase.
If we cut the maintenance to one release (instead of the 2 we have now)
and switch development to a rolling release that is usable I agree with
you we can get something reasonable.

Keep in mind that most people are *perfectly* ok with no updates, as
long as we still care for security updates and really only critical
bugfixes I think a lot of people would be happy to run on a 'stable'
release that really is just a frozen development release that had a
month or two of stabilization (just like we do now) and then is left
mostly untouched.

> > So things aren't perfect now they aren't as bad as you paint them to
> > be. The current anaconda mess is just a project management failure ...
> > nothing else really.
> 
> The current anaconda mess is an example I used in my post, but it's not
> the only one. I've been thinking along these lines for a long while, not
> related to any particular fire. It's a general perspective.

There is something I like in what you say, but sound extremist.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York



More information about the devel mailing list