RFC: Rethinking EPEL at FUDcon Lawrence 2013

[Tomáš Smetana]

On Thu, 22 Nov 2012 10:56:33 +0100
Jan Pazdziora <jpazdziora at redhat.com> wrote:

> On Thu, Nov 22, 2012 at 10:15:30AM +0100, Matthias Runge wrote:
> >
> > 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.
> 
> [...]
> 
> > 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.
> 
> The schedules RHEL operates on are not necessarily aligned with the
> schedules of the individual components in EPEL. Having more channels
> / streams of EPEL could lead to unnecessary increase of work for
> maintainers who'd suddenly face much more complex rel-eng setup.

And does every package have to be present in all the channels? I can imagine
a package having a different maintainer in each channel or not to be present
in some at all: if maintaining more versions at once or backporting patches
is beyond the maintainers possibilities, he may decide to only re-package the
new upstream stuff in "unstable" or just backport critical patches to the
"old" channel.

Yes, I understand this may shift the complications to the users who will have
to invent more complicated yum configurations to get the right packages from
the right channels.

Regards,
-- 
Tomáš Smetana