[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Request for Policy Clarification



On Sun, 4 Nov 2012 09:55:35 -0600
inode0 <inode0 gmail com> 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

Attachment: signature.asc
Description: PGP signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]