By Jake Edge
October 17, 2008
The news
that Wikipedia was in the process of switching away from Red Hat and
Fedora—and to Ubuntu—has stirred up some Fedora
folks. The relatively short, 13 month support cycle for Fedora releases
was fingered as a major part of the problem in a gigantic thread
on the fedora-devel mailing list. Some would like to see Fedora be
supported for longer, so that it could be used in production environments,
but that is a fundamental misunderstanding of what Fedora has set out to
do.
The idea of supporting Fedora beyond the standard "two releases plus one
month", which should generally yield 13 months, is not new. It was, after
all, the
idea behind the Fedora Legacy
project. Unfortunately, Fedora Legacy ceased operations at the end of
2006,
largely due to a lack of interested package maintainers. So, calls for a
"long term support" (LTS) version of Fedora are met with a fair amount of
skepticism.
Just such a call went up in response to the Wikipedia news. Patrice Dumas
outlined the need:
[...] it seems to me that a true Fedora LTS is
missing, that would allow those who want things that are new, including
for testing but cannot afford changing everything each year (servers for
example or user desktops). It seems to me that fedora ends up being used
almost exclusively as single user desktop, so that testing of other
functionalities is likely to be less widespread.
Fedora is not meant for production use, nor for those who cannot upgrade at
least yearly. It has an entirely different mission, which
Jon Stanley sums up:
Well, in all fairness, Fedora's stated goal is to advance the state of
free software. You get that by being bleeding-edge. Unfortunately,
being bleeding edge also means not being suitable for production
environments - these are two fundamentally incompatible goals. This is
why Red Hat Linux split into two - Fedora and RHEL. RHEL is a
derivative distribution of Fedora.
Many believe that folks who want "Fedora LTS" would be better served by Red
Hat Enterprise
Linux (RHEL) or, for those that do not want to pay for a distribution with
support, an RHEL
derivative such as CentOS or Scientific Linux. But those don't have the
package diversity available with Fedora. A stable release would also want
to freeze major packages at a particular version—only backporting
security fixes into that version—which is definitely not what is done
with Fedora while it is being supported. Dumas wants to see something that
finds a middle ground:
Fedora legacy (or fedora lts) would not be the same than centos. Maybe a
Centos + repository with more recent stuff would be, but currently I
think that there is something in the middle between fedora and centos
that is missing.
The Extra Packages for
Enterprise Linux (EPEL) project is meant to help fill that gap, by
maintaining additional packages—beyond what Red Hat
maintains—for RHEL and compatible distributions. Typically, though,
those packages will also be held at a version level that will, with time,
grow rather obsolete, at least to those who want to more closely follow the
upstream project. And, of course, there aren't as many packages available
for the enterprise distributions, even with EPEL, as there are for Fedora.
It would seem the classic tension between "bleeding edge" and stable as
described by Stanley. Though it isn't clear how it would solve that
problem, there are calls for reviving Fedora Legacy. There are few opposed
to the idea of continuing Fedora support—if enough people can be
found to do it—but the implementation details seem to bog things down.
There is a bit of a "chicken and egg" problem in that attracting package
maintainers is hard to do without a project to point to, but convincing the
Fedora Engineering Steering Committee (FESCo) that it is worthwhile without
having those maintainers will be difficult.
One of the sticking points is the availability of
infrastructure—servers and bandwidth primarily—for any nascent
legacy project to use. The Fedora board is seen as being resistant to
allowing the use of the Fedora infrastructure for such a project. In
response to someone who pointed out that the board's approval is not
required, Dumas disagrees:
When it requires cooperation with the infrastructure, it does. It is
also possible to start something external like rpmfusion, but the amount
of work is very big. My proposal only made sense if the economies of
scale realized by working inside the fedora project were realized.
Still, if somebody provides the infrastructure, sure I'll try to help
with a project similar than the one I proposed, but I cannot myself do
anything for the infrastructure part.
There is also the question of what kind of guarantees a legacy project
would make about how long it would support older releases. Dumas and
others seem to be in favor of essentially no commitment, maintainers would
continue supporting their packages for as long as they wished. While
there is some attraction to that idea—it certainly reduces the number
of maintainers required—it is unclear that it actually provides a
useful service. The idea that some security fixes are better than none is
attractive, but David Woodhouse cautions against that view:
If we present the _appearance_ of a distro with security updates, while
in fact there are serious security issues being unfixed, then that is
_much_ worse than the current "That distro is EOL. Upgrade before you
get hacked" messaging.
For anything to have the Fedora name on it, it _must_ have guaranteed
security fixes for at least the highest priority issues.
As the original Fedora Legacy project wound down,
it left just this kind of impression by promising support,
but often not delivering it. For several years, updates
for serious security problems were delivered late, if at all. Any new
effort in that
direction would have to be very clear about what it was delivering
and how it planned to get the job done.
A project that offered few, if any, guarantees would not be seen as
something very useful, but making guarantees that don't get met is far
worse.
While there are clearly Fedora users that would be interested in hanging on
to their operating system for longer than one year, it isn't clear that there
are enough of them—and, more importantly, enough maintainers—to
make a legacy project successful. Agreement on the goal of the project,
along with the promises it would make to adopters is important. It is
difficult to see how the Fedora powers-that-be could allocate resources to
such a project without those things. As Shmuel Siegel points out:
You are looking for
infrastructure support from Fedora without indicating that there is a
benefit to Fedora. Supply without demand is no more useful than demand
without supply. Since Fedora views itself as "the cutting edge distro",
you have an uphill PR fight. Give the Fedora project a reason to spend
some of their limited resources on you. At least let them know your
target audience and why they would be interested.
At least at this point, it doesn't seem like a revival of Fedora Legacy is
in the cards, which leaves the problem unaddressed. Perhaps adding enough
additional packages to EPEL will allow CentOS to truly become "Fedora
LTS". It should be noted that while the original concern that LTS users
might be switching to Ubuntu could well be true, Ubuntu LTS doesn't have a
solution to the problem of package versions slowly getting obsolete either.
Newer packages and
stability are fundamentally at odds—trying to solve that problem is
probably far too large of a job for any community distribution.
(
Log in to post comments)