Photon landing strategy

Gijs Kruitbosch gkruitbosch at
Tue Mar 28 12:22:58 UTC 2017

On 28/03/2017 00:51, Justin Dolske wrote:
> One option is a project branch. We did this with Australis, but the 
> pretty major downside is that you get very little user testing. And of 
> course you have to keep that branch up to date, monitor for test and 
> performance regressions, etc.
Yeah, I would prefer not to do this (again).

> The other option is to land Photon pieces behind prefs. This is the 
> option I'd strongly prefer, as it lets us get Nightly testing and the 
> benefits of our normal infra come by default. Of course, nothing is 
> free... Some things are difficult to put behind a pref. And we'd 
> likely need to run a non-Photon project branch, to make sure Aurora 
> isn't busted after an uplift.

I would actually probably prefer ifdefs over prefs for some things. As 
you note, some things (e.g. XUL layout and CSS) are a bit tricky to 
adjust solely based on a pref. Ehsan also recently posted to 
dev-platform about the runtime impact of prefs (though we could improve 
that by using defineLazyPreferenceGetter).

Testing is going to be a major pain here no matter what we do. In 
theory, prefs can be adjusted at runtime. In practice, it doesn't seem 
particularly great to have to support that toggling (for things like XUL 
layout), but we might not have a choice if we want decent test coverage 
of new/changed features (and don't want to lose test coverage of the 
older features, either, as we'll still be shipping them on 55/56).

If we end up e.g. forking browser.xul and/or some of the XBL bindings 
behind a pref (similar to what we're doing with about:preferences), we 
lose a lot of the benefits of not using a project branch, in that we'd 
still have to merge all the things all the time, except then we'd have 
to do it manually. :-(

On 28/03/2017 08:06, Chris Peterson wrote:
> Instead of using a separate project branch for running tests on 
> non-default pref values, you might consider adding a new pseudo 
> "platform" to Treeherder. Stylo has "linux64-stylo" builds+tests 
> running on inbound/etc (bug 1330666) and Quantum Render has 
> "linux64-qr" builds+tests running just on central.
browser and devtools mochitests aren't the quickest tests to run as it 
is. I can't see releng jumping up and down with excitement about us 
doing this, though I agree it would help with the "how do we test both 
UIs" conundrum.

> It seems like some of the smaller visible UI changes could probably 
> ship in 55/56 without needing a pref. Users probably won't notice some 
> of the UI polish features until everything is into place in 57. 
> Shipping these smaller bits in 55/56 would give us more testing. 
Can you elaborate on this? What are "small visible UI changes" that 
users "won't notice"? I'm skeptical these even exists, looking at (for 
instance) things like . comes to mind... And yes, of course these are 
extreme examples, but I'm also looking at the mockups I've seen and 
thinking I don't see anything that falls in the "small polish" category 
in our main theming & structural changes.

I do assume we're going to be shipping any perf improvements we 
find/make ASAP.

~ Gijs

More information about the Photon-dev mailing list