From Fedora Project Wiki

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

Interested People

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

# Name Interested Participating Remarks
1. Jeroen van Meeuwen X X Capable of and willing to do the work
2. Rahul Sundaram X X Interested in maintaining packages
3. Gerold Kassube X X
4. Sandro Mathys of ETHZ X (?)
5. Marcus Moeller X (?)
6. Itamar Reis Peixoto X X Interested in making this feature happen :-)
7. Scott Williams X X
8. Christoph Wickert X X Interested in maintaining packages
9. Randy Berry X X Interested in maintaining packages
10. Fabian Affolter X X
11. Ayrton Araújo X (?) Interested in maintaining packages
12. Henrique Junior X (?) Interested in maintaining packages
13. Daniel Bruno X (?) Interested in maintaining packages
14. Tulio Macedo X (?)
15. Rodrigo Padula X - Interested in maintaining packages, recruit new colaborators and work to organize Latam ambassadors to support this feature
16. Dyemes Cartegyano X (?)
17. Jan Klepek X X Interested in maintaining packages
18. Rafael Gomes X X Interested in maintaining packages
19. Alex Hudson X X Interested in packages, deployment scenarios.
20. Edney Matias of Prognus Software Livre X X Interested as a consumer.
21. Rex Dieter X X
22. Leonardo Vaz X (X) Defining project specs and maintaining updates
23. Nelson Chan X ?
24. Luis Felipe Marzagao X ? Fow now, as a consumer.
25. Yaakov M. Nemoy X - I need a good laugh every now and then.
26. Marco Somoza X X I have the desire to help, just don´t know how :)
27. Stefan Hartsuiker X X Interested in the infra
28. Thomas Janssen X X Interested in maintaining packages
29. Steven M. Parrish X X Interested in maintaining packages, infrastructure
30. Filipe Rosset X X Interested in maintaining packages
31. Rodrigo Menezes X X Very interested, I can test packages
32. Davi Vercillo X X Interested in maintaining infrastructure
33. Alexandre Duarte Sousa X X Interested in maintaining infrastructure, packages, documentation...
34. Sudheer Satyanarayana X X Interested in maintaining infrastructure and packages
35. Susmit Shannigrahi X X Will contribute as per requirement.
35. iskida X X Interested as consumer. (exp: production servers)
36. Siddharth Sharma X X Interested as contributor, bug fixing motif and other packges
37. Klaatu X X Interested as contributor, can help with packaging or testing

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 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
  1. Keep branches open
  2. Keep tags/targets open
  3. Bodhi updates submission
  4. ...
Infrastructure
  1. Koji maintenance
  2. Mirror / disk space
  3. 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

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

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

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.

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

Retrieved from "https://fedoraproject.org/w/index.php?title=CDE_SIG:Extended_Life-cycle_Support&oldid=383376"