<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I'm hoping to have this tool running in automation (on Try to start) in the next few work days then we can get it running more often (e.g. Nightlies). Of course it only covers things that screenshots are taken of which we can easily tweak over time.<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Follow along in bug 1169179 and bug 1231408.<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Matthew N.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 10, 2015 at 3:13 PM, Emma Humphries <span dir="ltr"><<a href="mailto:emma@mozilla.com" target="_blank">emma@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">MattN was demoing me a tool he was building as a side project that in<br>
conjunction with a tool he used for participation during the Australis<br>
work (showing screenshots to users and asking if things were broken)<br>
might be something that could be used to leverage participation in<br>
finding regressions in these changes.<br>
<br>
Matt's plate is more than full, so this is something which would need<br>
people assigned to it if it would be of benefit.<br>
<div class="HOEnZb"><div class="h5"><br>
On Thu, Dec 10, 2015 at 2:43 PM, Sylvestre Ledru <<a href="mailto:sylvestre@mozilla.com">sylvestre@mozilla.com</a>> wrote:<br>
> Hello,<br>
><br>
> First, I understand your pain and frustration. We have plan to simplify the<br>
> aurora/devedition uplift processes for next year.<br>
><br>
> I think we can give a try to your proposition in 46. However, we think we<br>
> will need two things:<br>
> * usage of a a=css-image-only approval<br>
> * a hook to verify the list of files being touched in the commit.<br>
><br>
> I reported this bug:<br>
> <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1231768" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1231768</a><br>
> to get this hook.<br>
><br>
> Thanks for this proposition,<br>
> Sylvestre<br>
><br>
><br>
><br>
> Le 27/11/2015 11:21, Lawrence Mandel a écrit :<br>
><br>
> Good discussion. A few thoughts on top and in summary of what's already been<br>
> said:<br>
><br>
> - I think experimenting is good. 46 seems like a good time in that we have<br>
> some time to work out all of the details.<br>
> - The relman team agrees that while we do get value from Aurora approvals<br>
> there is a lot of overhead here - and I would say ideally there are better<br>
> activities on which to spend our time.<br>
> - Much of the value that relman gets out of approvals should be obtainable<br>
> from other sources. We should identify the real value (I think we can do<br>
> this quickly) and figure out how to get this information from the pushlog<br>
> and other sources.<br>
> - There is an issue of trust. While many (in my experience the majority) of<br>
> Mozilla devs have demonstrated that they make good decisions wrt uplifts,<br>
> some don't. Having an open m-a branch is scary. We really need to keep this<br>
> branch stable. This is the one piece of value, control over landings, that<br>
> will be hard to replace. I agree with experimenting as we don't know how<br>
> much actual value we're getting with our current model.<br>
><br>
> Sylvestre - Can we please put this on our list to discuss in Orlando and<br>
> come back with either a commitment to do what Gijs has proposed or an<br>
> alternative proposal?<br>
><br>
> Lawrence<br>
><br>
> On Thu, Nov 26, 2015 at 7:28 AM, Gijs Kruitbosch <<a href="mailto:gijskruitbosch@gmail.com">gijskruitbosch@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Time for a recap now this discussion has died down a little.<br>
>><br>
>> TL;DR: I would like to experiment with this for the 46 cycle to see how<br>
>> this works in practice. If we find it has negative effects, we can stop<br>
>> doing it (immediately; we don't need to wait for the end of the cycle...).<br>
>> If we find it has broadly positive effects (ie doesn't lead to more breakage<br>
>> than usual), we can look at broadening the set of things we uplift without<br>
>> going through the formal approval process we currently use.<br>
>><br>
>> On 20/11/2015 19:22, Gijs Kruitbosch wrote:<br>
>>><br>
>>> I would like to propose that we eliminate the explicit aurora approval<br>
>>> requirement for changesets that meet ALL of the following criteria:<br>
>>> - only change CSS and/or image files<br>
>>> - are landing in the first 4 weeks of the aurora cycle;<br>
>>> - have landed on m-c and stuck<br>
>><br>
>><br>
>> On 20/11/2015 19:33, Robert Kaiser wrote:<br>
>>><br>
>>> How many of those do we have every cycle (i.e. is it enough that it gives<br>
>>> us a significant benefit and even warrants discussion)?<br>
>><br>
>> I don't know. I tried to find out, and it's hard to get that information.<br>
>> I'm fairly sure it's a comparatively small (<10%) subset of the patches that<br>
>> gets uplift, though.<br>
>><br>
>> I think it warrants discussion because I think there is broad agreement<br>
>> from relmgmt, QE and engineers that the current status quo is not ideal, but<br>
>> less agreement on what we should be aiming for instead. I'd like us to<br>
>> experiment and evolve our strategy here. This is not me personally going<br>
>> "ugh, I wish the patches I wrote didn't have to do this approval dance".<br>
>> This is me going "I wonder if this is a good set of things to use to evolve<br>
>> how we deal with approvals" (though full disclosure, because of the type of<br>
>> patches I often write, this probably does benefit me personally more than it<br>
>> will some other people). I'll get back to this point replying to some of the<br>
>> other posts further downthread.<br>
>>><br>
>>> What's the definition of "have stuck"? For how long?<br>
>><br>
>> "landed on m-c without being backed out". I don't really want to use extra<br>
>> criteria like "landed and stuck for X days" because I think the criteria are<br>
>> already pretty narrow, and adding verification burden here is not going to<br>
>> help materially.<br>
>><br>
>> On 20/11/2015 19:34, Chris Peterson wrote:<br>
>>><br>
>>> Why not allow any code change to be uplifted to Aurora based on the<br>
>>> developer's discretion? Or allow a patch's reviewer to a+ for Aurora uplift?<br>
>><br>
>> I think "developer's discretion" alone is not likely to be conducive to<br>
>> stability. I think patch reviewer and/or third person review by another<br>
>> person (not necessarily relman) might be interesting to explore, but still<br>
>> more high-risk than what I am suggesting. As an experiment, I'd like to<br>
>> start with what I originally suggested. We can evaluate after 1 cycle (or<br>
>> before if it blows up in our face).<br>
>><br>
>> On 20/11/2015 19:55, Liz Henry (:lizzard) wrote:<br>
>>><br>
>>> I could be ok with us outlining this kind of criteria and letting<br>
>>> developers know they can land their own changes in some cases.   Verifying<br>
>>> the fix on m-c (by someone other than the developer) might help too.<br>
>>><br>
>>> But, what those cases are, I'm not entirely sure.  I think there have<br>
>>> been css only uplifts that cause significant regressions.   Now, me<br>
>>> reviewing them isn't going to catch those regressions. But my being aware of<br>
>>> a cluster of uplift requests can mean I know to ask QE for extra testing in<br>
>>> particular areas. I factor the uplift action into a more holistic view of<br>
>>> what's happening across the board for a release and the amount of change and<br>
>>> risk we're looking at. That isn't always visible to the developers<br>
>>> requesting uplift.<br>
>>><br>
>>> Gijs you mention devs not being "required" to do this. I wonder if this<br>
>>> process might normalize uplifting things that could just as well ride the<br>
>>> trains.<br>
>>><br>
>>> The value of asking people to ask for uplift is sometimes in that they<br>
>>> take their changes more seriously. Often, people talk to me first on irc<br>
>>> before even asking, and during that conversation they find more work to do,<br>
>>> they think about testing or verifying fixes, or I uncover more uplifts that<br>
>>> need to happen for their work to land on aurora.<br>
>><br>
>><br>
>> I think all of these paragraphs point to a single (valid!) concern:<br>
>> uplifting things increases instability. We can contain the risk of<br>
>> instability by not uplifting things, or at least by asking for automated<br>
>> tests and/or manual QE, or restricting what things we uplift (interface<br>
>> changes, patch size, l10n concerns, etc. (l10n being a bit special because<br>
>> there are other reasons besides stability)).<br>
>><br>
>> But as dbaron and past have pointed out (and as I've discussed with Liz<br>
>> privately), realistically part of the issue is that we often don't get QE<br>
>> verification or crash-rate-combatting until we get to beta/release. That<br>
>> means nightly and, to a slightly lesser degree, aurora, are both not<br>
>> particularly stable, and that that stability is not completely dependent on<br>
>> how strict we are with uplifts.<br>
>><br>
>> It's very hard to assess the success of the current system at increasing<br>
>> stability because there is no way to know "what would have been". We don't<br>
>> know if developers or relman are overly cautious or not cautious/strict<br>
>> enough, unless we experiment. Because nobody seems particularly happy with<br>
>> the current state of things, I would like us to experiment. :-)<br>
>><br>
>><br>
>> So perhaps my original phrasing was clumsy. I would like us to experiment<br>
>> with being "more permissive" about uplifts, and I'm purposefully starting<br>
>> out with a subset of patches that I suspect are lower risk, and where there<br>
>> is a clear secondary benefit (ie devedition theming).<br>
>><br>
>> I believe it's probably equally useful to take a hard look at improving<br>
>> quality on nightly and aurora through other means. I'll open a separate<br>
>> thread about that.<br>
>><br>
>> ~ Gijs<br>
><br>
><br>
><br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> firefox-dev mailing list<br>
> <a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a><br>
> <a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/firefox-dev</a><br>
><br>
</div></div></blockquote></div><br></div>