[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Plan for tomorrow's EPEL meeting - 2009-10-02



On Fri, Oct 2, 2009 at 4:00 AM, Till Maas <opensource 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]]


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]