On Thu, 22 Nov 2012 10:56:33 +0100 Jan Pazdziora <jpazdzi...@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 _______________________________________________ epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
