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
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 | |
| 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 from [Software Livre] | X | X | Interested as a consumer. |
| 21. | Your Name | - | - | - |
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
- 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;
- 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).
- 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
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.
- 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.