RFC: Rethinking EPEL at FUDcon Lawrence 2013

Kevin Fenzi kevin at scrye.com
Sat Dec 8 20:15:37 UTC 2012


On Fri, 07 Dec 2012 13:49:56 -0700
Dmitry Makovey <dmitry at athabascau.ca> 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. 

We have such a process in the karma process in bodhi. ;) 

> 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.

Currently it's 2 weeks in testing or +3 karma. 

In practice I almost never see anything get +3 karma, which shows that
we have few testers. Also, seldom do things get -3 karma. ;( 

kevin


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20121208/d1ab6cf9/attachment.sig>


More information about the epel-devel-list mailing list