On Monday 27 August 2007, Mike McGrath wrote:
Personally I think documenting these processes is a lot of work with
questional benefit. It seems to me more logical to be reactive to
this.
I'm afraid I'll have to disagree here and would not be comfortable with using
packages from or seriously contributing to such a project. Mileages vary, of
course, but I'd be surprised if it were just me.
One Scenario: work hard to produce a great package of something popular and
complex, succeed, get it through the review process, ship it in EPEL. Months
pass, users are happy, and build things on top of the EPEL package and its
configuration. Then, someone finds out that there's a conflict/unwanted
upgrade or something like that problem with the package and something in some
channel or derivative distro.
I can't come up with a good way to react to this kind of a situation without
breaking something, and just throwing things out there to see if something
breaks is not what I'd expect from a project like EPEL. The _best_ case is
that people report the problem and the reactive fix will "only" result in
wasted packager/maintainer/reviewer resources.