THE EPEL WIKI PAGES ARE NO LONGER USED AND ARE OUT OF DATE - SEE THE EPEL DOCS FOR UP TO DATE INFORMATION.
(These wiki pages are being kept for historical reference only.)
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
- 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.redhat.com against the package.
- Discussion takes place on epel-devel for a minimum period of 1 week (need some way to short-circuit this for critical security updates - i.e. remote root).
- Item is added to agenda for discussion at weekly EPEL meeting.
- If a majority of those present at the EPEL meeting concur, the incompatible upgrade can be built.
- 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.
- Package MUST remain in testing for at least 2 weeks, regardless of received karma. In bodhi, 'Auto-request stable?' MUST NOT be checked.
- 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
- How to short-circuit process for critical security updates
- 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.
- How to enforce the mail to epel-announce? Maybe have the chair of the EPEL meeting send it?