On Sun, 4 Nov 2012 09:55:35 -0600 inode0 <ino...@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
signature.asc
Description: PGP signature
_______________________________________________ epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
