On Thu, 28 Jan 2016 11:08:45 -0800
Adam Williamson <adamwill(a)fedoraproject.org> wrote:
> Well, this kind of question would probibly be better on the
> epel-devel list, but otherwise:
> And you can ask for an exception. This would entail pushing the new
> version to testing and leaving it there a while, mailing
> epel-announce to note that there's an incompatible version in
> testing and please test and then another note before you push it
> stable to give them a heads up. You may want to wait and push it
> stable at the same time as the next .X release comes out.
FWIW, I think that policy could do with less central oversight and
more maintainer responsibility.
Well, FWIW, I don't think there is much central oversight really.
People make their case to the list and unless someone says
"Oh no, you didn't think of X" people go ahead with the exception.
I guess the page could make it more clear that it's not some high
I don't think it's at all reasonable to expect the typical
maintainer to be capable of backporting security fixes to releases
which are unmaintained upstream. I think it would be absolutely a
better policy to give maintainers freedom to bump to a new release
series when the current release series becomes unmaintained upstream,
with some guidelines and pointers on a responsible way to manage this
Well, it kinda of depends on the package(s) in question...
Red Hat can pay dozens of engineers lots of money to work full time
maintaining code that upstream has abandoned, Fedora/EPEL cannot.
Anyhow, if you want to discuss epel policy please do post to the
epel-devel list and/or bring it up at the weekly epel meeting (wed at
19UTC in #fedora-meeting).