From Fedora Project Wiki

m (Add the link to epel-devel for convenience.)
(Note about disabling autokarma.)
Line 12: Line 12:
# If a majority of those present at the EPEL meeting concur, the incompatible upgrade can be built.
# 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.
# 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 2 weeks, per the normal EPEL update policy.
# Package MUST remain in testing for at 2 weeks, regardless of received karma.  In bodhi, 'Auto-request stable?' MUST NOT be checked.
# When pushing package to stable, the maintainer '''MUST''' send another e-mail to epel-announce.
# When pushing package to stable, the maintainer '''MUST''' send another e-mail to epel-announce.



Revision as of 18:30, 1 March 2017

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.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 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.
  6. Package MUST remain in testing for at 2 weeks, regardless of received karma. In bodhi, 'Auto-request stable?' MUST NOT be checked.
  7. When pushing package to stable, the maintainer MUST send another e-mail to epel-announce.

Procedure for other packages

For other - non-security - updates, the maintainer MUST NOT push those types of changes to the stable package. Instead, a new package must be made, pass review, and be branched for EPEL only.

For example, an rdiff-backup upgrade for the reasons of an incompatible protocol change would be required to create a new package, called rdiff-backup12 and have that package pass review and imported into CVS.

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?