Re: Request for Policy Clarification

[Kevin Fenzi]

On Sun, 4 Nov 2012 09:55:35 -0600
inode0 <inode0(a)gmail.com&gt; wrote:

>  In the past I have requested some clarification and suggested what I
>  thought was reasonable for an EPEL policy governing which packages
>  were allowed into EPEL. I understand my vision of this policy is more
>  strict than the EPEL community finds agreeable so this time I am only
>  asking that the EPEL community clarify its own policy and advertise
>  that on its wiki so users of EPEL can understand what the policy
>  actually is. 
Yeah, agreed. 

>  Here are some examples of why I am perpetually confused about it.
...snip...

It's worth noting here that when I did the wiki redesign for EPEL, I
dropped the FAQ page in hopes that the redesign would answer questions
in the right place for the right people. Sadly, others kept re-adding
the FAQ and links to it, so I suppose it's here to stay. I don't like
how it mixes contributor and end user questions and I never went over
it after the last redesign, so some of it's from long long ago. ;) 

>  What users of RHEL in particular need to know is which channels in
>  terms they can understand are assured to be conflict free and which
>  aren't. The above examples of the policy descriptions currently
>  provided by EPEL aren't consistent even at an abstract level. 
Right. 

>  Can we just get this defined in a way that can be understood by
> users?
>  Even in the absence of any policy change? 
My proposal: 

For RHEL6: All channels listed at: 
http://koji.fedoraproject.org/koji/taginfo?tagID=140

which currently is: base, optional, ha, lb

For RHEL5: All channels listed at: 
http://koji.fedoraproject.org/koji/taginfo?tagID=81

which currently is: base, vt, productivity

>  I'd also like to request a bit more formal timeline of what a
> user can
>  expect to happen after reporting a package that is in EPEL that
>  shouldn't be. In my experience many EPEL maintainers respond quickly
>  to such reports but I've seen others sit in BZ for more that a month
>  before someone else takes action on it. Since removing existing
>  packages in EPEL, especially ones that appear newer than their RHEL
>  counterparts, can be dangerous to RHEL users I think removal actions
>  should happen very quickly to minimize the danger. 
Agreed. 

How about:

File a bug against the component. 
Wait a week. 
File a rel-eng trac ticket pointing to the bug and a rel-eng person can
clean it up. 

Or perhaps we just ask for a rel-eng ticket with the epel maintainer
CCed and can wait there for a week for them to deal with it? 

Whatever works, but I agree it would be good to handle these quickly. 

kevin