On 11/21/2012 11:21 AM, Stephen John Smoogen wrote:
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.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?
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?