RFC: Rethinking EPEL at FUDcon Lawrence 2013

Dennis Jacobfeuerborn dennisml at conversis.de
Fri Dec 7 22:12:51 UTC 2012


On 12/07/2012 09:49 PM, Dmitry Makovey wrote:
> On 12/06/2012 06:23 PM, Joe Julian wrote:
>>> However many intermediate repos we put in place, these unstable
>>> updates *have* to be allowed to go into epel-stable eventually.
>>> Otherwise, we put epel-stable users at risk for unpatched security
>>> flaws.
>> My point is, we already do. If an admin has to lock their packages to
>> specific versions to keep their system working, then they are not going
>> to be getting security updates.
> 
> sounds to me that there needs to be a clean procedure on promoting from
> testing to stable. My opinion would be to let the users trigger that in
> cases where developers are busy with other things. So if we have
> foo-1.x.rpm in epel-stable, and foo-2.y.rpm in epel-testing and I, as a
> user see that it fixes bug/vulnerability/deprecates/etc. foo-1.x.rpm, I
> would:
> 
> 1. submit request for promotion from testing to stable,
> 2. ...
> 3. profit?
> 
> #2 can go as "need X votes in bugzilla" or "need N confirmations from
> users" something tangible and simple to follow for all involved.

Packages need maintainers. If the maintainer of a package cannot deal with
these issues any more due to time constraints or lack of interest then the
package needs to be orphaned to give others the opportunity to pick up the
maintainer role and if that doesn't happen it should be removed.

A package should never be promoted to stable without an active maintainer
who can make proper decisions about the impact this will have. Users should
be able to become maintainers but they certainly shouldn't be able to just
trigger such a move.

Regards,
  Dennis




More information about the epel-devel-list mailing list