RFC: Rethinking EPEL at FUDcon Lawrence 2013

[Joe Julian]

On 11/21/2012 11:21 AM, Stephen John Smoogen wrote:
> OK from the various problems with various packages and the needs of
> packaging groups for a faster place for development and users for a
> more stable and knowing release cycle.. I would like to open the floor
> to what we can do to make EPEL more useful to both groups as best as
> possible with the goal that the proposals are finalized by FUDcon
> Lawrence and work on them completed within 6 months.
>
> 1) Formalize what EPEL does and how it does it.
>   - Who gets to decide about updates
>   - How do we update major items (regularly after a RHEL release? after
> a Fedora release?)
>   - How do we say "we can't support this architecture/release" anymore?
> 2) Make sure it is documented what the Fedora Build System can do for
> us and what it can't.
>   - Repotags (yes/no)
>   - Multiple channels for devel, testing, stable, old (yes/no)?
>   - Building for PPC/etc architectures when we don't have systems anymore?
>
As much as I've balked at not being able to get the more stable 
GlusterFS release(s) into EPEL, I do agree with the Enterprise standpoint.

GlusterFS, prior to 3.1.6 had no business being in an enterprise repo. 
It wasn't ready. Unfortunately, since it was already in, it wasn't 
possible to push any of the versions that/were/ enterprise ready. If it 
had been kept out until it was ready, I would sure have a much easier 
time supporting it. Better than half the time someone comes into 
#gluster, they're running the EPEL version and I have to tell them to 
upgrade because whichever bug they're experiencing has already been fixed.

This should also be taken into account in this process:
- Should a package reside outside of EPEL until it's "enterprise ready"? 
IMHO, that's what Fedora's for.
- How is it decided that a software is "enterprise ready", and who gets 
to decide?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20121121/bf7e472f/attachment.htm>