Incompatible upgrades policy

Background

Incompatible version upgrades in EPEL are to be avoided. However, in certain situations, they are unavoidable. An example of such a situation would be a security update that is difficult/impossible to backport. This policy aims to both discourage incompatible upgrades for trivial reasons, while allowing them for security updates where the version of the software in question is no longer maintained upstream and the maintainer is unable to backport just the security fix.

Process for incompatible upgrades

  1. Send e-mail to epel-devel with details of the proposed upgrade. Include items such as the CVE of the security issue to be fixed, and/or an upstream bug tracker reference (if applicable). Also reference a bug in Bugzilla against the package.

  2. In the case of a critical CVE the maintainer MAY build the package and submit it to bodhi for testing. 'Auto-request stable?' MUST NOT be checked.

  3. File an EPEL issue. This can be done while discussion is ongoing; please link to the thread in the mailing list archive so the EPEL Steering Committee can monitor the discussion and know when it is ready to be discussed.

  4. After a week of mailing list discussion, an EPEL Steering Committee member will add the meeting tag and the issue will be discussed at the next weekly meeting.

  5. If a majority of Steering Committee members present at the EPEL meeting concur, the incompatible upgrade can be built, if it has not been already.

  6. At the same time that the update is submitted to bodhi for testing, the maintainer is responsible for sending e-mail to epel-announce announcing the incompatible upgrade and specific actions that users must take in order to continue using the software.

  7. Package MUST remain in testing for at least 1 week, regardless of received karma. In bodhi, 'Auto-request stable?' MUST NOT be checked.

  8. When pushing the package to stable, the maintainer MUST send another e-mail to epel-announce.

Procedure for other packages

For other - non-security - incompatible updates, the maintainer MUST NOT push those types of changes. Consider shipping an alternatively named new package (e.g. foo2) to provide the newer version.

Discussion points

  1. Approval process - majority of those present seems to be lax, but being there’s no body such as FESCo in "charge" of EPEL (yes, I realize that FESCo has oversight, but oversight != make day-to-day decisions such as these), I’m not sure what else to put there.

  2. How to enforce the mail to epel-announce? Maybe have the chair of the EPEL meeting send it?

Want to help? Learn how to contribute to Fedora Docs ›