The entire QA team (and the entire anaconda team, for that matter)
is
currently spending virtually all its time trying to help bash the new
anaconda into something vaguely resembling shape for a fairly
arbitrary
release deadline, so we can ship something called 'the Fedora 18
stable
release' without *completely* corpsing Jimmy Fallon-style as we do
the
release announcement ("suuuure, this is a stable release..." *giggle*
*giggle* *guffaw* *full-blown laughing fit*). We've barely looked at
the
desktop or the update mechanism or anything else. Stuff in Fedora
regresses all over the place...there all sorts of weirdness in how
fairly basic bits of our OS work, like updates and login and various
other crap. We can't really look in a mirror and say that, say,
Fedora
17 is a serious stable operating system release by any reasonable
definition. It's a stable Fedora release, and we all know what that
is.
We had a feature for a smooth boot process back in F12, remember?
where
everything was polished and had the same background and you didn't
see
any mode transitions? How's that working these days? It was supposed
to
be a feature of our operating system. We almost got it done for one
release, and have been consistently regressing it ever since. That's
not
what stable, mature operating systems do.
Adam is telling the inconvenient truth here, and I agree. We really shouldn't pretend
that Fedora is a "stable OS". Unfortunately none of Linux distributions really
is (now talking about desktop distributions, not server ones).
But... the fact we're doing a poor job doesn't mean that some "general
users" are not using Fedora happily. They may the lucky ones (no update breakages) or
they have a power-user friend who help them from time to time. If we cut them off
completely, I'm afraid Fedora would become a niche distribution, with just a fraction
of its previous user base. I think that wouldn't be a good outcome. But I agree we
need to simplify things and decrease the currently required resources (QA, package
maintainers, releng, etc) so that the quality can go up.
My idea would be to have two releases:
== Fedora Stable ==
* A release for general users with low volume of security fixes and important bug fixes.
** Bug fixes would be pushed monthly and QA would be performed on this monthly batch of
updates.
* Released every 18 months, supported for 18+2 months (2 months to give people time to
upgrade to the next Fedora Stable).
** Why 18 months? Because for general users it is annoying to upgrade every year, but OTOH
our package maintainers wouldn't probably like supporting 2-year-old packages. 18
months is still an increase from current 12 months of support, but if we stop releasing
two parallel stable releases, we can make the support longer with the same energy spent.
** Just one stable release instead of two. Can anyone tell me a compelling argument for
having two stable releases (F16, F17) in parallel? I don't see any. The current model
probably evolved because we wanted new software fast, but upgrading every 6 months would
discourage a lot of users. Let's be honest - yes, it will contain old packages and
yes, it is intended for conservative users. For the other group we will have Fedora
Rolling.
* More reliable upgrades, although less convenient for power users. Instead of current way
of often-broken system upgrades, our upgrade tool would install a clean system, remount
/home, and try to install all GUI applications that the user had manually installed in his
previous system.
** General user wouldn't see a difference, but we could achieve much higher upgrade
success rate.
** Power users would have to manually transfer /etc changes, add custom repos, etc. But if
you need to do that only once every 18 months, it's not so bad. Also, a lot of power
users would use Fedora Rolling instead, so they would not be affected at all. Some power
users can even do unsupported yum upgrades (as many of them do now), so they won't be
affected by it either.
* There would probably have to be a stabilization period before new Fedora Stable is
released. So Branched release would exist for a short time. But it would be e.g. 3 months
every 18 months, instead of current 3 months every 6 months. Also, with Fedora Rolling
being generally working (as opposed to current Rawhide), the period could be much shorter:
1-2 months.
== Fedora Rolling ==
* Rolling release similar to Fedora Branched, but with higher quality standards. This
would target Linux power users wanting leading-edge software.
** Bodhi karma would be used for issuing updates. Because a lot of people would be using
Fedora Rolling, the quality would be higher than current Fedora Branched (where just a
tiny number of people actually run it and report problems).
* Big disruptive changes (like usrmove or sysv->systemd) would be allowed to happen
just in a concrete time slots, e.g. once a quarter.
** A special tool would be required, because not every change can be performed using just
RPM packaging.
** The changes would be heavily tested by QA beforehand.
** Further package updates would be blocked until you finish the disruptive change.
* Installer images would be released as needed. For example after a big disruptive change
happens, we would release a new installer image so that folks don't have to install
the system and then immediately go through the disruptive change.
** This process would also allow Anaconda devs to continuously work on the installer and
update it continuously with core system changes. Currently they can't work on Rawhide
because "Rawhide is just broken". Fedora Rolling would allow them that.
** Transitions Fedora Stable -> Fedora Rolling wouldn't probably be officially
supported, the same issue as for usual upgrades - too many things can go wrong.
== Appendix ==
Q: What would happen to Rawhide?
A: There might be technical reasons why we need a repository for pushing bleeding-edge
broken packages. If there is such reason, Rawhide would stay, but we would make clear it
is just a _repository_ full of bleeding-edge packages, but it is not a _release_. So it is
not intended to be run, it just a repo for fixing building problems.