On Thu, 2016-01-28 at 12:00 -0700, Kevin Fenzi wrote:
> On Thu, 28 Jan 2016 10:03:08 +0000
> Jamie Nguyen <j...@jamielinux.com> wrote:
> 
> > Hi,
> > 
> > Distributions like RHEL and Debian have a very strict update policy
> > (for good reason). People expect stability and don't want surprises.
> > 
> > When CVEs arise, patches can often be backported. Nginx 1.8.1 recently
> > fixed three CVEs and I've backported to Nginx 1.6.x on EL7.
> > 
> > Unfortunately, Nginx 1.0.x on EL6 is too old; I gave it a good shot
> > but backporting the patches reliably without creating new CVEs is
> > beyond my expertise. Nginx 0.8.x on EL5 is prehistoric.
> > 
> > I've had a couple of bug reports recently suggesting that I rebase
> > Nginx to 1.8.1 on all branches. On the one hand, I want to avoid
> > causing surprises and breaking somebody's website. On the other hand,
> > these vulnerabilities do need to be fixed. (The approach I took with
> > the Tor package is to always use the latest stable release on all
> > branches, which is working well.)
> > 
> > What do people think? Should I go ahead and update all branches (with
> > appropriate migration notes)?
> 
> 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.

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.

Red Hat can pay dozens of engineers lots of money to work full time on
maintaining code that upstream has abandoned, Fedora/EPEL cannot.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Reply via email to