Fedora and long term support
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:
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:
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:
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:
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:
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:
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.