RFC: Rethinking EPEL at FUDcon Lawrence 2013

[Matthias Runge]

On 11/21/2012 08:21 PM, 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?
> 
For some packages, keeping them up to date and 100% compatible to a
version released, when that package was added to EPEL is simply
impossible for volunteers.
As (bad) example, php in RHEL 6 is php-5.3.3, latest stable release is
php-5.4.8; I'm taking my hat off for everybody back-porting fixes for
every error fixed in between those releases.

<rant>
When reading php's changelogs, you ask yourself, how you were ever able
to use that software on a server.</rant>

But clearly there's software requiring more frequent upgrades than other
software. An example for the former is php, for the latter the Apache
web server, which has been stable (and compatible) for at least 7 (?) years.


To come to my proposal:
We should have something like channels, for simplicity analogous to EPEL
releases (i.e. RHEL releases). When a newer channel is opened (i.e. a
newer RHEL minor version is released), EPEL package maintainers should
be allowed to do upgrades.

A configuration would look like today, but would also include
repositories for those (additional) sub-channels. So users could stay at
the base channel as long as the release lives or could upgrade by adding
a sub channel.

The question here is: can we realize this setting somehow in our repos
(and also in our builders)? Honestly, I don't know.
-- 
Matthias Runge <mrunge at matthias-runge.de>
               <mrunge at fedoraproject.org>