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

[Kevin Fenzi]

Here's the topic list for tomorrows EPEL meeting, which will take
place at 21:00 UTC in #fedora-meeting on irc.freenode.net. 

- Status update on action items
   - smooge: Blocking packages already in RHEL
   - jds2001: Incompatible version upgrades process/guidelines 
- Open Floor

If there is something else that folks would like to discuss, please
followup to this email or mention it in the Open Floor section of the
meeting at the end. Hope to see everyone there!

kevin

[Till Maas]

On Thu, Oct 01, 2009 at 11:39:48PM -0600, Kevin Fenzi wrote:
>  Here's the topic list for tomorrows EPEL meeting, which will
> take
>  place at 21:00 UTC in #fedora-meeting on irc.freenode.net. 
>  
>  - Status update on action items
>     - smooge: Blocking packages already in RHEL
>     - jds2001: Incompatible version upgrades process/guidelines 
>  - Open Floor
>  
>  If there is something else that folks would like to discuss, please
>  followup to this email or mention it in the Open Floor section of the
>  meeting at the end. Hope to see everyone there! 
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:
https://bugzilla.redhat.com/show_bug.cgi?id=466720

Regards
Till

[Kevin Fenzi]

On Fri, 02 Oct 2009 10:00:40 +0200
Till Maas <opensource(a)till.name&gt; wrote:

>  On Thu, Oct 01, 2009 at 11:39:48PM -0600, Kevin Fenzi wrote:
>  > Here's the topic list for tomorrows EPEL meeting, which will take
>  > place at 21:00 UTC in #fedora-meeting on irc.freenode.net. 
>  > 
>  > - Status update on action items
>  >    - smooge: Blocking packages already in RHEL
>  >    - jds2001: Incompatible version upgrades process/guidelines 
>  > - Open Floor
>  > 
>  > If there is something else that folks would like to discuss, please
>  > followup to this email or mention it in the Open Floor section of
>  > the meeting at the end. Hope to see everyone there!
>  
>  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:
>  https://bugzilla.redhat.com/show_bug.cgi?id=466720 
Would you care to step up and help? Jon has been busy lately and unable
to finish the draft of the incompatible version upgrades doc. I'm
waiting for that to be fleshed out and approved before pushing
rdiff-backup updates. 

Would you care to make a draft of it? I had some ideas in the list a
while back on what should be in it. 

If not, I can try and write one up this weekend, but I've been busy
too. 

kevin

[Jon Stanley]

On Fri, Oct 2, 2009 at 4:00 AM, Till Maas <opensource(a)till.name&gt; 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]]

[Michael Stahnke]

On Fri, Oct 2, 2009 at 11:19 AM, Jon Stanley <jonstanley(a)gmail.com&gt; wrote:
>  On Fri, Oct 2, 2009 at 4:00 AM, Till Maas
> <opensource(a)till.name&gt; 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(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/epel-devel-list
>  
I'll miss the meeting today.  At Puppetcamp.

stahnma