[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: Plan for tomorrow's EPEL meeting - 2009-10-02
- From: Jon Stanley <jonstanley gmail com>
- To: EPEL development disccusion <epel-devel-list redhat com>
- Subject: Re: Plan for tomorrow's EPEL meeting - 2009-10-02
- Date: Fri, 2 Oct 2009 12:19:39 -0400
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]