Plan for tomorrow's EPEL meeting - 2009-10-02
Jon Stanley
jonstanley at gmail.com
Fri Oct 2 16:19:39 UTC 2009
On Fri, Oct 2, 2009 at 4:00 AM, Till Maas <opensource at till.name> wrote:
> It seems to me that the decission finding process in EPEL fails. The
> discussion about incompatible version upgrades is on the agenda for
> several months now. At least one bug about this: the inability to use
> rdiff-backup from Fedora with EPEL will be a year old in 11 days:
This is entirely my failing in failing to write something down - I
have a strawman in my head, and have for awhile. So let's do that
here :) (also on the wiki when it's available again)
= 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 or high-priority
bugfix updates (i.e. data corruption).
== 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, 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 ==
# 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?
[[Category:EPEL]]
More information about the epel-devel-list
mailing list