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

[Michael Stahnke]

On Fri, Oct 2, 2009 at 11:19 AM, Jon Stanley <jonstanley at gmail.com> wrote:
> 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]]
>
> _______________________________________________
> epel-devel-list mailing list
> epel-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/epel-devel-list
>

I'll miss the meeting today.  At Puppetcamp.

stahnma