CDE SIG:Extended Life-cycle Support

Extended Life Cycle

Summary

In pursuit of greater adoption of the Fedora Linux distribution in corporate desktop environments we seek to extend Fedora's life cycle with a yet to be determined additional period of time in which systems installed with Fedora can continue to receive security updates.

Owner

• Name: Jeroen van Meeuwen
  • Email: kanarip@kanarip.com

Interested People

Name	Interested	Participating	Remarks
Jeroen van Meeuwen	X	X	Capable of and willing to do the work
Gerold Kassube	X	X
Sandro Mathys of ETHZ	X	(?)
Marcus Moeller	X	(?)
YourName	-	-	-

Current status

• Targeted release: Fedora 42
• Last updated: Monday July 6th, 2009
• Percentage of completion: 00%

Detailed Description

Corporate desktop environments want to run Fedora as the primary Linux distribution of choice, especially when their server environment is already running one of Fedora's downstream or derivative distributions such as Red Hat Enterprise Linux or CentOS (maybe including Scientific Linux, and possibly others).

Besides corporate desktop environments, we have the (less interesting) (home- and SOHO-) users themselves, as well as (some smaller environments) running Fedora on servers.

One of the major downsides to having Fedora on a desktop environment is, though, that the user is required to upgrade every year. On the desktop hardware device's lifecycle of most commonly 3 years, this means a given system needs to be installed, then upgraded, then upgraded, with just one month of time to choose between Fedora N+1 or Fedora N+2.

Say a desktop environment runs Fedora 9 today, then within a month after Fedora 11 is released, the user can choose to either upgrade to Fedora 10 (N+1), or Fedora 11 (N+2). This is not considered a suitable amount of time for corporate desktop environments, where projects need to be defined, testing needs to be performed, resources have to be alocated, etc, before any of the actual work can be done.

The only reason that makes upgrading the distribution a requirement is the continuous availability of security updates.

Therefore, the Extended Life Cycle feature for Fedora 12 is aimed to provide those that need it with a little more preparation time by providing security fixes only, for a yet to be determined period of time after a given Fedora release becomes what we now call End-Of-Life (EOL).

FAQ

1. Q: Why not CentOS?
   • The CentOS project, or it's upstream, has a release cycle of approximately three years -not a steady release cycle of three years but that's what it turns out to be. This "disqualifies" the distribution(s) as desktop Linux distributions for some environments, as desktops tend to need to run the latest and greatest for as far the latest and greatest lets them.

Benefit to Fedora

With potentially greater adoption in corporate environments, two major benefits arise;

1. The corporate perspective on a distribution such as Fedora, with different requirements to how Fedora should behave (distribute policies for PolicyKit amongst a larger group of systems, for instance).
2. Potential larger participation in both Fedora development as well as upstream.

Neither of these is new, in that some businesses already participate and give their perspective, but we think this might increase if and when the Fedora Linux distribution becomes a more viable option for corporate desktop environments.

Scope

Opt-in on ELC Support
Note that the following items may only apply to those that opt-in on ELC support

To ensure the Fedora 12 Extended Life Cycle feature is a success, we are looking at changes to procedures and access levels in the following components of the Fedora Infrastructure and release procedures;

• CVS commit access (PackageDB?)
• Koji build access (PackageDB?)
• Bodhi updates pushing (PackageDB?)
• Bodhi updates management (Releases currently known as EOL will need to remain available in Bodhi)
• RPM Package Signing
• DeltaRPM Packages
• Mirrors
• "EOL", approximately 13 months after General Availability becomes End-Of-Support (EOS)
• End-Of-Life is then the point where ELC Support ceases to continue to provide security updates for a given EOS release, after a yet to be determined period of time after a release enters it's EOS stage.
• Bugzilla maintenance
  • auto-closing of bugs against EOL releases -> different notice
  • "open" releases available to log bugs against?
• Bugtriaging processes
  • Different notices in bugs

How To Test

There is currently no test plan other then that we think this feature is to continue business as usual, just a little longer.

User Experience

Users, whether consumer desktops or in corporate desktop environments, will see their options change from 2 releases to upgrade to (when Fedora N becomes EOL, Fedora N+1 and N+2 are available) to 2+X releases. X is dependent on the period of time between EOS and EOL where the Extended Life Cycle feature would provide security updates for.

Dependencies

The success of this feature depends on the willingness of parties involved, such as FESCo, but also package maintainers that opt-in to ELC Support, as well as the Fedora Project Board, Advisory Board, Release Engineering, the community and the number of users that see value in this feature.

The providing of security updates up and until 6 months after what we now call EOL for a given release, costs approximately 1 FTE. If 40 people opt-in on ELC Support, that's 1 hour per person per week average. This 1 FTE is including the number of actions performed by Release Engineering for maintaining koji as well as bodhi and the signing and pushing of updates.

Master Mirror Space

From Josh Boyer's reply in the thread on fedora-devel-list

> This used to be an issue, in that we had to move
> older releases to alt.fp.o in order to make space for the new release.  I
> believe we still do that, so either the yum.repo.d config files for the EOL
> release would need to be changed, or we'd have to grow a lot more mirror
> space.

Update Push Times

From Josh Boyer's reply in the thread on fedora-devel-list

> It takes 3+ hours to mash f9-updates right now. 
> Keeping
> that time duration in the official updates pushing for an EOL release would
> be really annoying.  Particularly since we are already going to hit some
> major
> time hurdles as F10 and F11 age and definitely when we add F12.

Contingency Plan

None necessary for the inclusion of the feature before Fedora 12, but the success of the feature needs to be revisited before Fedora 14 -which is when we have had 5 months of ELC support.

In order to determine the success, we seek to use the numbers of Smolt, and MirrorManager statistics. We'd compare the numbers at the time of a release becoming EOS against a snapshot of those same numbers while the release is EOS and before it becomes EOL.

Documentation

• No upstream documentation, as this is a Fedora feature entirely.

Notes

• The initial ELC Support duration would be 6 months, prolonging the life cycle of a Fedora release to 19 months.
• For the period of time between a Fedora release becoming EOS, and that Fedora release becoming EOL, only security updates will be provided.
• We do not guarantee binary compatibility with the versions of applications or libraries that were in the Fedora release before it became EOS.
• We do not guarantee a stable API or ABI to the applications and libraries that we provide security updates for.

Release Notes

These are just notes that the people that are interested in this feature as part of Fedora 12 themselves would need to take into account (see also Documentation => Notes above):

• For the period of time between a Fedora release becoming EOS, and that Fedora release becoming EOL, only security updates will be provided.
• We do not guarantee binary compatibility with the versions of applications or libraries that were in the Fedora release before it became EOS.
• We do not guarantee a stable API or ABI to the applications and libraries that we provide security updates for.

Comments and Discussion

• See Talk:Features/Extended_Life_Cycle