On 25/11/13, 10:25 , Philip Chee wrote:
Original blog post at
<http://msujaws.wordpress.com/2013/11/21/running-a-backout-branch-with-mercurial/>
An other problem with identifying a patch as Australis specific are
patches with bits in Australis/browser and bits in Gecko (e.g. layout or
content). The bits in Gecko are necessary for Australis to work but are
otherwise not specific to Australis and indeed might contain some
welcome optimizations that would be useful for other Gecko based software.
Phil
I believe this problem is too tiny to worry about. By definition,
Australis changes are almost entirely in browser/ (with sprinklings of
toolkit/ and teensy bits of widget/cocoa and layout|gfx for mac titlebar
stuff, IIRC). All of the general perf improvement stuff that was
required for some of the Australis work (e.g. SVG cache improvements,
windows titlebar hittest improvements) has landed on m-c pre-Australis
and is therefore also on holly. So, so far, there is almost nothing that
fits the bill of the issue you described.
The backout branch isn't permanent, so even for whatever fraction of
fractions that could potentially be adapted to work on the backout
branch with the "old" layout of the browser, the most that would happen
is that such changes are delayed for a cycle or two before riding the
trains. We're not near a new ESR so I don't see any issues there either.
Much more importantly, I suspect that unless there is compelling
evidence that such changes should be uplifted (e.g. security, large perf
improvements with low risk, etc.), we'd keep them out of holly because
we want a stable base for Aurora, and holly will see a lot less testing
than mainline m-c. We're already experiencing this now as a seemingly
innocent and well-tested patch for gfx regions is causing perma-orange
on holly but not on m-c. (
https://bugzilla.mozilla.org/show_bug.cgi?id=942250 )
~ Gijs
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform