From Fedora Project Wiki

(initial version)
 
(add category)
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
Should explain history of how EPEL came to be and list some of the folks who have been involved.
Should explain how we try not to replace RHEL packages, how we don't do incompatible upgrades in releases, etc.
Should explain the rules for what we do or don't replace, etc.
= History and Philosophy of EPEL (Extra Packages for Enterprise Linux) =
= History and Philosophy of EPEL (Extra Packages for Enterprise Linux) =


Line 16: Line 12:


TODO: add more here. Pull from old faq/update document.
TODO: add more here. Pull from old faq/update document.
[[Category:EPEL]]

Revision as of 19:44, 19 March 2011

History and Philosophy of EPEL (Extra Packages for Enterprise Linux)

History

The EPEL project was born out of Fedora. There was a need for quality 3rd party packages for Enterprise Linux using the already existing Fedora infrastructure. Early on there was a move to help consolidate existing 3rd parties, which for various reasons ended up mostly failing. The EPEL project was formed as a Project rather than a special interest group. This entailed a steering committee, formal votes and regular progress reports to FESCo. After several years, it was determined that EPEL could function just as well as a SIG where folks just got things done and reached consensus, so EPEL moved to that model.

TODO: Add dates and times and more info here.

Philosophy

EPEL strives to never replace or interfere with packages shipped by Enterprise Linux. Packages in EPEL should be supported for the full life cycle of the Enterprise Linux they are build against. Additionally, they should strive to never require manual update procedures or processes. During the stable part of the EPEL cycle, packages shouldn't update in a way that changes the user experence or otherwise adds more than bugfixes.

TODO: add more here. Pull from old faq/update document.