Photon landing strategy

Justin Dolske dolske at mozilla.com
Tue Mar 28 20:06:33 UTC 2017


On Tue, Mar 28, 2017 at 5:22 AM, Gijs Kruitbosch <gkruitbosch at mozilla.com>
wrote:

On 28/03/2017 00:51, Justin Dolske wrote:
>
>
> 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).
>

Yeah, #ifdefs are fine. The primary goal is just to make sure we can get
testing of Photon stuff on Nightly-55, Nightly-56, and the 57 train, while
being able to turn it off elsewhere. Prefs have a few (obvious?) advantages
when they're feasible, but otherwise I'm not too concerned about the
specific mechanism.


> 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. :-(
>

Yes, that's one of the costs. I don't see a better alternative. (So be
mindful about forking, and carefully consider if alternatives might have a
bit more up-front effort but be a win overall.)

Justin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/photon-dev/attachments/20170328/675cd2c0/attachment-0001.html>


More information about the Photon-dev mailing list