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