EPEL incompatible upgrades policy

Incompatible upgrades policy

This page is a draft only
It is still under construction and content may change. Do not rely on the information on this page.

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 or high-priority bugfix updates (i.e. data corruption).

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.redhat.com against the package.
2. 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)
3. Item is added to agenda for discussion at weekly EPEL meeting
4. If a majority of those present at the EPEL meeting concur, the incompatible upgrade can be built.
5. At the same time that the update is submitted to bodhi, 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.

Discussion points

1. How to short-circuit process for critical security updates
2. 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.
3. How to enforce the mail to epel-announce? Maybe have the chair of the EPEL meeting send it?