On Fri, Oct 2, 2009 at 11:19 AM, Jon Stanley <[email protected]> wrote: > On Fri, Oct 2, 2009 at 4:00 AM, Till Maas <[email protected]> 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]] > > _______________________________________________ > epel-devel-list mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/epel-devel-list >
I'll miss the meeting today. At Puppetcamp. stahnma _______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
