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 | 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. | Your Name | - | - | -
} Current status
Detailed DescriptionCorporate 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
Benefit to FedoraWith potentially greater adoption in corporate environments, two major benefits arise;
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. ScopeTo 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;
How To TestThere is currently no test plan other then that we think this feature is to continue business as usual, just a little longer. User ExperienceUsers, 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. DependenciesThe 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 SpaceFrom 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 TimesFrom 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 PlanNone 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
Notes
Release NotesThese 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):
Comments and Discussion |