Photon landing strategy
gkruitbosch at mozilla.com
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
> 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
https://xkcd.com/1172/ 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
More information about the Photon-dev