Slowing down Fedora Core

[Posted January 25, 2006 by ris]

A discussion has been going on in the fedora-devel list, starting with this post from Gilboa Davara, requesting that Fedora Core 4 (FC4) remain supported, by the Fedora Project, until FC6 is released.

Last week FC3 went into maintenance mode with the Fedora Legacy Project, just as FC5 Test2 was released, as has been the typical schedule so far. The final FC5 release is scheduled for mid-March, about two months away.

According to this proposal, beginning with FC4, the Fedora Project would be responsible for supporting two releases while finalizing a third release. This would delay a transfer to Fedora Legacy for a few months and a few more bug fixes. Most of all, this proposal is an expression of concern about the Fedora Legacy Project's ability to support old releases.

It is true that a Fedora release does not receive the same level of support once it is transferred to Fedora Legacy. When the Fedora Project supports a release, they provide security updates, bug fixes, and occasionally upgrades and enhancements for various packages. These package updates can be seen in each weekly Distribution page, in the Package updates section. The Fedora Legacy Project provides security updates only.

So the level of support from Fedora Legacy is a bit less than that from the Fedora Project, but if it is only for a few months how much does that really matter? As long as your stable system can remain secure until you are ready for an upgrade, a few bug fixes aren't going to matter much. The volunteers building security updates for Fedora Legacy are competent and first and foremost they are building updates for themselves. They have a vested interest in making sure these updates work. Others should be able to benefit from their work, but those who want more from Fedora Legacy are encouraged to participate. Fedora Legacy is a community project, so those who want more from the project should be prepared to help accomplish their own goals.

It is also true that Fedora Legacy had a hard time getting up to speed. Early releases came into the Legacy project with large numbers of outstanding security problems. Both Fedora and Fedora Legacy have had some severe growing pains, and they are not finished ironing out the process. This transition was smoother than the last; FC3 has very few outstanding security issues. We should expect that as FC4 moves into its Legacy status, the process will be even smoother, especially if more people get involved and help out.

Some users expressed distaste with the word "legacy". The dictionary definition:

1. Money or property bequeathed to another by will.
2. Something handed down from an ancestor or a predecessor or from the past

seems to capture the meaning of Fedora Legacy quite well, but for those who have worked on "legacy systems" this distaste is understandable. Many suggestions were given for changing the name of Fedora Legacy to something more palatable. Some of the suggestions were not bad, but ultimately people should ask themselves if they would rather have Fedora Legacy volunteers keep busy by updating the documentation, website, mailing list, and so on, to reflect a name change; or would their time be better spent maintaining the project's five currently supported releases (Red Hat Linux 7.3, Red Hat Linux 9, FC1, FC2 and FC3)? I would chose the later.

A more serious concern is that the process of moving to Fedora Legacy is difficult, or at least less than obvious. To begin with, users need to be aware that the status of their system has changed and that is time for them to make a decision of some kind. Should they decide not to upgrade, the move to Fedora Legacy requires that they change some configuration files to look at different repositories. There is nothing automatic about the process. A conscious decision must be made to either upgrade to the next Fedora release, or get support from Fedora Legacy. Users who wait for the little update icon to appear may unintentionally leave their systems at risk.

The Fedora Legacy Project is not insensitive to these concerns. Jesse Keating has proposed some changes for Fedora Legacy that will make an easier transition for users who want to continue running older releases. Fedora Legacy has come a long way since FC2 came into its care. It can be, and should be, even better by the time FC6 test2 is released and FC4 moves into its purview.

Fedora Core was envisioned as a fast moving distribution. Already it has slowed down, from six months between releases to nine+ months between FC4 and FC5. For those who like a slower pace, there are plenty of slower paced distributions available and for diehard Fedora fans, there is the Fedora Legacy Project.

For those people who argue that they should be able to skip a release and go from a supported FC4 to a supported FC6, ask yourselves this: would you really switch to FC6 on the day it's released? More likely you'd be asking for another month, and then another month after that. Meanwhile many Fedora users are happy with the current pace and would prefer that Fedora engineers spend the time between FC6 test2 and FC6 polishing FC6, not squashing old FC4 bugs.

Warren Togami expressed it quite well:

I strongly believe that an important goal of Fedora is rapid forward progress in Open Source Software. That is where the Red Hat engineers should be focusing their time and energy.

Fedora is supposed to be a community project, and Legacy is where fate of an older distribution is put within the hands of the community. If there is sufficient interest in maintaining a distro, then Legacy will keep it alive. If a given distro falls into disrepair, then the decision will eventually be made to retire it in order to better allocate resources on distributions that the users care more about.

Fedora Core should remain fast-paced. When Fedora engineers are concentrating on finalizing a release they should not be burdened with maintaining two other releases. Fedora Legacy is working and it can and will get better, especially if more people volunteer their time to help. If Fedora is too fast paced for you, and you can't or won't help the Legacy project achieve your goals, find another distribution that moves at a slower pace. I have little list that might be helpful in that regard.

Slowing down Fedora Core

Posted Jan 26, 2006 3:44 UTC (Thu) by vmlinuz (guest, #24) [Link] (1 responses)

The final FC5 release is scheduled for mid-March, about four months away.

Not quite sure what sort of calendar you're using, but I make mid-March less than 2 months away...

Slowing down Fedora Core

Posted Jan 26, 2006 3:46 UTC (Thu) by corbet (editor, #1) [Link]

You know, time can really drag when you're waiting for a distribution release...or so it seems. Fixed.

Fedora Legacy has major problems

Posted Jan 26, 2006 4:19 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] (1 responses)

I've run Fedora distros a long time. Fedora Legacy was a nice idea, but it just hasn't worked; the rate of security patches coming out of Legacy has been far short of what is required.

Truth in advertising requires the admission that distributions that have transitioned to Legacy no longer have effective security support, especially when it comes to kernel bugs.

If you want to argue otherwise: until recently, FC2 was the newest distro supported by Legacy. They did a kernel update on March 28, and none since then. This means that all kernel bugs found in the last 10 months are still present in FC2 as maintained by Legacy.

Legacy has done a better job with security bugs in applications; in many cases they can just build a new release against older libraries, and ship.

Perhaps a compromise is possible: the Fedora Core team could continue providing kernel security updates for a period long enough to allow Fedora users to confidently skip every other update (e.g. go from FC4 to 6 to 8, etc), while asking Legacy to only support userspace.

Kernels present special difficulties.

Posted Jan 26, 2006 14:33 UTC (Thu) by brugolsky (guest, #28) [Link]

I agree that there are problems with Legacy, and that kernel updates are the most troublesome issue. The biggest difficulty with your proposal is, as I'm sure Dave Jones will confirm, that changes in the kernel (and latent bugs in some userspace components) keep breaking user-space components such as udev, libselinux, alsa, etc., so it is not easy or sufficient to, say, upgrade everyone to 2.6.15.1. One can't just drop the kernel SRPM for the currently supported release into the build system for the various older releases without ifdefs sprinkled throughout the kernel spec file and/or other package updates. Since the kernel and the userspace components have separate maintainers, coordinating an update is a bit of a problem.

The alternative is to attempt to cherrypick and backport fixes. That can be a lot of work -- work that detracts from improving the current, supported releases.

Slowing down Fedora Core

Posted Jan 26, 2006 7:02 UTC (Thu) by ronaldcole (guest, #1462) [Link]

That "little update icon" hasn't worked properly for me in a looooong time. It seems to work right after you log in, and then never again until you log off and log in again. It's similarly broken in RHEL3 and RHEL4.

Slowing down Fedora Core

Posted Jan 26, 2006 11:09 UTC (Thu) by gdt (subscriber, #6284) [Link] (1 responses)

I run a large university network. We frequently find compromised Red Hat Linux 7 machines, and last year we even found a RHL 4 machine.

What I'd dearly love from all distributions is for them to ship with a date after which the default route cannot be installed without explicit action which ackowledges that the distribution has no maintenance for security bugs. That action should require the use of "vi" or the jumping of some other fence that requires a level of UNIX clue.

Projects like Fedora Legacy could ship with an RPM that shifts the date.

Turning off a distribution

Posted Jan 26, 2006 17:35 UTC (Thu) by smoogen (subscriber, #97) [Link]

That sounds like a good idea.. but property changes hands a lot, and they will just blame the last sys-admin for making the change. [Having seen this before where we would turn off network ports for boxes that didnt have patches, and the port had to be manually turned back on.. or someone would move the machine to another port etc etc.]

In the end, it is an administrative action on the part of the network administrators to say what is acceptable to be placed on their networks. If they do not have that power, then they need to clearly get it in writing who does and tell them that they are the ones who are responsible for billable overtime.