From Fedora Project Wiki

Summary

The change moves expected package lifetime to that of a Red Hat Enterprise Linux minor release.


Owner

Detailed Description

Extra Packages for Enterprise Linux is a sub-project of Fedora which recompiles various Fedora packages against various Red Hat Enterprise Linux releases. When EPEL was started, RHEL lifetimes were 5 years and it was thought that the repository could have similarly long lifetimes. Major rebasing of versions were not to be allowed, and fast moving software was frowned on.

Over time, the lifetime of a RHEL release grew, and the way RHEL releases rebased themselved overtime also changed. This has meant that packagers in EPEL were bound to support software longer than RHEL did and unable to rebase like RHEL could.

The current proposal is closely linked to release based composes but does not depend on it. The changes are as follows:

Packagers commit to maintaining software in EPEL for at least one RHEL minor release or 13 months, whichever is shorter. If a packager needs to stop maintaining the software, they should do the following

* announce on epel-devel list that they are no longer able to
  maintain the package and give the reasons. If someone can take it
  over they can do so here. 
* release one final version with an additional file named
  'README-RETIRED.txt'  in the %docs section which says this software
  is retired. 
* wait until that package arrives in updates.
* let the EPEL release manager know that the package needs to be
  retired for the next release. 

Otherwise the latest update of the package will be retagged for the next compose of EPEL and will appear without problems.

If the situation requires a major ABI/API change (security, a new minor compose occurs, a new LTS package is released) a packager should announce to epel-devel and put in a ticket in the epel pagure instance to track. Updates can then be made and will show up in either /updates/ or the next major.minor compose.

Benefit to Fedora

  • Packagers will feel more likely to make their packages available in
 EPEL. 
  • Users of EPEL will have more software and know it is being kept up.


Scope

  • Other developers:
  • Policies and guidelines: The above need to be coded clearer
  • Trademark approval: N/A

Known Change Impacts

How To Test

User Experience

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?)
  • Contingency deadline:
  • Blocks release?
  • Blocks product?

Release Notes