On Thu, 22 Nov 2012 10:56:33 +0100
Jan Pazdziora <jpazdziora(a)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