CDE SIG:Extended Life-cycle Support

= Extended Life-cycle Support =

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

Owner

 * Name: Jeroen van Meeuwen
 * Email: [mailto:kanarip@kanarip.com kanarip@kanarip.com]

Interested People
This table tracks who is interested in this project (as a consumer?), and who is participating (as a contributor).

Current status

 * Targeted release:
 * 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 allocated, 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

 * 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.


 * Q: What work is included / affected?
 * Release Engineering
 * Keep branches open
 * Keep tags/targets open
 * Bodhi updates submission
 * Infrastructure
 * Koji maintenance
 * Mirror / disk space
 * PackageDB mass-update ACLs possibly including removing watchcommits / watchbugzilla on EOL, but provide opt-in for existing maintainers
 * Bugzilla watchers / zappers / bots
 * Use fedora-release-els
 * separate gpg key
 * els updates channel enabled on install
 * assure upgrade path
 * sec. update package nvr always lower then next release's Everything/ nvr
 * autoqa?
 * keep branches open for additional 6 months
 * keep branches open for additional 6 months

Other Miscellaneous Quick Notes
How to enable (re-)opt-in on upgrade:


 * In an upgrade from Fedora 11 to Fedora 12, fedora-release = 12 can obsolete fedora-release-els < 12, while fedora-release-els = 12 can still be explicitly selected

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
To ensure the Fedora Extended Life-cycle Support initiative is a success, we are looking at changes to procedures and access levels in the following components of the Fedora Infrastructure, support and release procedures;


 * dist-git 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 Extended Life-cycle Support ceases to continue to provide security updates for a given EOS release.
 * 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 Support 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 X, but the success of the feature needs to be revisited before Fedora X+2, which is when the effects of this initiative would start showing, and again at Fedora X+3 -which is when we have had 5 months of Extended Life-cycle Support for Fedora X.

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.

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