On Fri, Aug 2, 2013 at 11:02 PM, Mike Hommey <m...@glandium.org> wrote:
> On Sat, Aug 03, 2013 at 02:14:10AM +0200, Brian Smith wrote: > > On Sat, Aug 3, 2013 at 12:51 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com > >wrote: > > > > > This adds too much risk of security patches failing to backport from > > > > > >> mozilla-central to ESR 24. Remember that one of the design goals of > ESR > > >> is to minimize the amount of effort we put into it so that ESR doesn't > > >> slow down real Firefox. AFAICT, most people don't even want ESR at > all. > > >> So, a constraint to keep ESR 24 compatible with GCC needs to include > > >> some resources for doing the backports. > > >> > > > > > > How does this add too much risk? Patches that we backport to ESR are > > > usually fairly small, and there is already some risk involved as the > > > codebases diverge, of course. > > > > > > > There are two kinds of risks: The risk that any developer would need to > > waste time on ESR just to support a product that isn't even Firefox on a > > platform that virtually nobody uses, and the risk that comes with making > > any changes to the security fix that you are trying to backport. The > ideal > > case (assuming we can't just kill ESR) is that your backport consists of > > "hg graft" and "hg push" and you're done. That is what we should optimize > > for, as far as supporting ESR is concerned. You are right, of course, > that > > ESR and mozilla-central diverge as mozilla-central is improved and there > > are likely to be merge conflicts. But, we should not contribute to that > > divergence unnecessarily. > > All the refactoring we're doing is already making these divergences > more significant than supporting an older toolchain does. You can't just > hg graft and hg push over changes such as the s/PRBool/bool/ type > changes (and we're going to do a lot of them over the lifetime of > ESR24). I doubt we'd want to backport these refactorings to ESR. > > So while i feel for your concern, it just hasn't much to do with the > toolchain problem. Also note that we don't know what code the ESR security fixes will touch as we're making other changes on trunk, so trying to avoid conflicts with those unknown future changes seems like premature optimization of some sort. Cheers, Ehsan _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
