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