<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2017-03-30 15:33 GMT+02:00 Mike Conley <span dir="ltr"><<a href="mailto:mconley@mozilla.com" target="_blank">mconley@mozilla.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Maybe I'm missing something, but I see the following advantages of this<br>
approach over using a project branch:<br>
<br>
1) Easy one: we don't have to maintain a project branch! No periodic<br>
merging. Presumably less probability of having to deal with merge<br>
conflicts due to changes in mozilla-central. No having to watch multiple<br>
trees.<br></blockquote><div><br></div><div>We'd still have to synchronize the fork with the backup and deal with conflicts, no matter whether they both live in on branch or in two separate ones. <br></div><div>That is unless you freeze the backup, but you could do that with a project branch as well.<br><br></div><div>I'm not actually a fan of project branches. I think they can be quite painful. I'm just not sure this is better.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
jaws and I maintained the Holly backout branch during the development of<br>
the Australis theme, and I remember that being a bit of a pain.<br>
<br>
2) Easy to manually turn on and off. Among other things, it will be<br>
easier for volunteer contributors to participate and try the new theme<br>
while it's being built, spot problems and file bugs against it (since<br>
they won't have to run a separate executable that updates on a different<br>
schedule).<br></blockquote><div><br></div><div>Forking the theme into a second folder is one thing; making it so that it's a theme that can be downloaded and installed is definitely not something I want to deal with. It's overhead we don't need. As I understand it, we're only talking about roughly six weeks here (the 56 cycle, since we'll probably spend the rest of the 55 cycle on prep work), so I think we should keep it simple.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3) Probably easy to programmatically turn on and off. I know that UR and<br>
UX is interested in doing experiments and science with the changes that<br>
we're making to ensure that we're actually making the browser experience<br>
better. Shipping it as a separate theme gives us the potential of<br>
turning it on temporarily for some subset of our user population to do<br>
A/B testing.<br></blockquote><div><br></div><div>For this to work we'd have to maintain this cumbersome development model through the 57 cycle, which sounds like a very undesirable side effect to me. I'd rather we used 56 vs. 57 for A/B testing.<br><br></div><div>dao<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm not wholly against a project branch, but I think there are some nice<br>
advantages of writing it as a separate built-in theme that we should<br>
consider as well.<br>
<br>
But I'm also pretty easy going. Do what works. :)<br>
<br>
-Mike<br>
<span class=""><br>
On 2017-03-30 4:42 AM, Dão Gottwald wrote:<br>
> It's quite possible. Could just be a different theme folder with a<br>
> build-time switch. However, I don't see how that's better than a project<br>
> branch. It seems like a different way to fork stuff with roughly the<br>
> same overhead due to having to synchronize it.<br>
><br>
> 2017-03-30 0:04 GMT+02:00 Mike Conley <<a href="mailto:mconley@mozilla.com">mconley@mozilla.com</a><br>
</span>> <mailto:<a href="mailto:mconley@mozilla.com">mconley@mozilla.com</a>>>:<br>
<span class="">><br>
> Hey folks,<br>
><br>
> Not sure if my suggestion got lost in the shuffle, or if it's<br>
> malodourous / obvious enough that it didn't prompt reply, but would<br>
> landing the appearance changes as a new complete theme be out of the<br>
> question? I know we're tearing out the support for that stuff, at<br>
> least for third-party extensions, but for this kind of theme<br>
> development, it seems quite well suited.<br>
><br>
> Or am I wrong?<br>
><br>
> -Mike<br>
><br>
> On 29 March 2017 at 08:37, Dão Gottwald <<a href="mailto:dgottwald@mozilla.com">dgottwald@mozilla.com</a><br>
</span><span class="">> <mailto:<a href="mailto:dgottwald@mozilla.com">dgottwald@mozilla.com</a>><wbr>> wrote:<br>
><br>
> 2017-03-29 14:18 GMT+02:00 Gijs Kruitbosch<br>
</span>> <<a href="mailto:gkruitbosch@mozilla.com">gkruitbosch@mozilla.com</a> <mailto:<a href="mailto:gkruitbosch@mozilla.com">gkruitbosch@mozilla.<wbr>com</a>>>:<br>
<span class="">><br>
> On 29/03/2017 11:42, Dão Gottwald wrote:<br>
>> 2017-03-28 14:22 GMT+02:00 Gijs Kruitbosch<br>
</span>>> <<a href="mailto:gkruitbosch@mozilla.com">gkruitbosch@mozilla.com</a> <mailto:<a href="mailto:gkruitbosch@mozilla.com">gkruitbosch@mozilla.<wbr>com</a>>>:<br>
<div><div class="h5">>><br>
>> On 28/03/2017 08:06, Chris Peterson wrote:<br>
>><br>
>> It seems like some of the smaller visible UI<br>
>> changes could probably ship in 55/56 without<br>
>> needing a pref. Users probably won't notice some<br>
>> of the UI polish features until everything is into<br>
>> place in 57. Shipping these smaller bits in 55/56<br>
>> would give us more testing.<br>
>><br>
>> Can you elaborate on this? What are "small visible UI<br>
>> changes" that users "won't notice"? I'm skeptical<br>
>> these even exists, looking at (for instance) things<br>
>> like<br>
>> <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1345989" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/<wbr>show_bug.cgi?id=1345989</a><br>
>> <<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1345989" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/<wbr>show_bug.cgi?id=1345989</a>><br>
>> . <a href="https://xkcd.com/1172/" rel="noreferrer" target="_blank">https://xkcd.com/1172/</a> comes to mind... And yes, of<br>
>> course these are extreme examples, but I'm also<br>
>> looking at the mockups I've seen and thinking I don't<br>
>> see anything that falls in the "small polish" category<br>
>> in our main theming & structural changes.<br>
>><br>
>><br>
>><br>
>> You're reading Chris too literally.<br>
> I fail to understand what is "literal" about my reading and<br>
> how yours is less so, and I'm disappointed that you're<br>
> turning an honest question into "you're (reading it) wrong".<br>
><br>
><br>
><br>
> No need to take it personally, I was just trying to answer your<br>
> question. Clearly, there is no UI change that is guaranteed to<br>
> go unnoticed with every single user. Reworded as "most users<br>
> won't notice", are you still skeptical that such changes exist?<br>
><br>
><br>
>> We're not trying to make it look like there were no<br>
>> changes at all between 54, 55 and 56, but the changes<br>
>> shouldn't particularly stand out and take away from Photon.<br>
>><br>
>> <snip><br>
>> For the visual refresh, I'm trying to be smart and divide<br>
>> the work into parts that can be tackled early and parts<br>
>> that should wait. Nihanth is going to start with<br>
>> integrating our new SVG toolbar button icons in bug<br>
>> 1347543 -- this should land when it's ready (I've checked<br>
>> with shorlander, he's fine with this)<br>
><br>
> I wouldn't have thought that changing the icons over to the<br>
> Photon icon set would be something we'd do before 57, as<br>
> that's pretty noticeable.<br>
><br>
> (To be clear, I'm not arguing that we shouldn't do this<br>
> stuff prior to 57 if people are on board with it, but to me<br>
> this is a surprising example of "small changes".)<br>
><br>
><br>
><br>
> From what I've seen the icons are a bit sharper and thinner, but<br>
> in the grand scheme of things it's a rather subtle and<br>
> incremental change.<br>
><br>
> dao<br>
><br>
> ______________________________<wbr>_________________<br>
> Photon-dev mailing list<br>
</div></div>> <a href="mailto:Photon-dev@mozilla.org">Photon-dev@mozilla.org</a> <mailto:<a href="mailto:Photon-dev@mozilla.org">Photon-dev@mozilla.org</a><wbr>><br>
> <a href="https://mail.mozilla.org/listinfo/photon-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/<wbr>listinfo/photon-dev</a><br>
> <<a href="https://mail.mozilla.org/listinfo/photon-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/<wbr>listinfo/photon-dev</a>><br>
<div class="HOEnZb"><div class="h5">><br>
><br>
><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> Photon-dev mailing list<br>
> <a href="mailto:Photon-dev@mozilla.org">Photon-dev@mozilla.org</a><br>
> <a href="https://mail.mozilla.org/listinfo/photon-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/<wbr>listinfo/photon-dev</a><br>
><br>
______________________________<wbr>_________________<br>
Photon-dev mailing list<br>
<a href="mailto:Photon-dev@mozilla.org">Photon-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/photon-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/<wbr>listinfo/photon-dev</a><br>
</div></div></blockquote></div><br></div></div>