On Thu, 28 Jan 2016 11:08:45 -0800 Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote: > > Well, this kind of question would probibly be better on the > > epel-devel list, but otherwise: > > > > https://fedoraproject.org/wiki/EPEL_Updates_Policy > > > > 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 overhead process. > I don't think it's at all reasonable to expect the typical Fedora > 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 > process. 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 on > maintaining code that upstream has abandoned, Fedora/EPEL cannot. Sure. 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). kevin
Attachment:
pgp0LZZv0obfz.pgp
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
