<div dir="ltr">+1 to everything Liz said. When I am reviewing the patch(es) nominated for uplift to Aurora, it serves several goals towards improving overall ship quality like:<br><ul><li>Has the patch landed in Nightly? And is the issue severe enough to be uplifted to Beta as well?<br></li><li>Have the code review comments been addressed?</li><li>Has the patch baked enough on Nightly?</li><ul><li>If the uplift request mentions a risk of startup crashes or stability, I try to let it bake for longer while observing Nightly crash-stats.</li></ul><li>If there are IDL changes, do we need to engage with AMO team?</li><li>Can we get the bug filer to verify the fix and possibly catch any unexpected fall outs early on in the cycle?</li><li>Do we need to request SV/QE team to do focused testing in this area as there are several uplifts happenings too close to each other?</li><li>Do we need to rel-note this?</li></ul><p>So while it may seem that most patches just pass through the RelMan team, we are using these patches to grab meta data that we use through the Aurora cycle and carry forward to Beta cycle to minimize disruptions to overall shipped quality.</p><p>Can we get smarter about grabbing this metadata from other places and not necessarily patch uplift requests? Yes. But we are not ready for that now. And DevEd44 stability is extremely poor atm and if we eliminate any checks at this point, we run the risk of destabilizing quality and stability even further.</p><p>Last but not the least, let me leave you with an example of a patch uplift that I reviewed in Aurora44 cycle where we were going to uplift an Image with the wrong resolution that I was able to catch when reviewing the patch uplift request. Please see comment 9 and comment 10 <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1221330#c9">https://bugzilla.mozilla.org/show_bug.cgi?id=1221330#c9</a>. I consider this as a value add that occurs from time to time when patches pass through the RelMan pipeline.</p><p></p><p>Thanks,<br>Ritu<br></p></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 20, 2015 at 11:55 AM, Liz Henry (:lizzard) <span dir="ltr"><<a href="mailto:ehenry@mozilla.com" target="_blank">ehenry@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>We were discussing similar ideas at our recent work week.  I think once we have Autoland we will be a lot closer to making this happen in other areas as well.<br><br></div>I could be ok with us outlining this kind of criteria and letting developers know they can land their own changes in some cases.   Verifying the fix on m-c (by someone other than the developer) might help too. <br><br></div>But, what those cases are, I'm not entirely sure.  I think there have been css only uplifts that cause significant regressions.   Now, me reviewing them isn't going to catch those regressions. But my being aware of a cluster of uplift requests can mean I know to ask QE for extra testing in particular areas. I factor the uplift action into a more holistic view of what's happening across the board for a release and the amount of change and risk we're looking at. That isn't always visible to the developers requesting uplift. <br><br></div>Gijs you mention devs not being "required" to do this. I wonder if this process might normalize uplifting things that could just as well ride the trains. <br><br></div><div>The value of asking people to ask for uplift is sometimes in that they take their changes more seriously. Often, people talk to me first on irc before even asking, and during that conversation they find more work to do, they think about testing or verifying fixes, or I uncover more uplifts that need to happen for their work to land on aurora. <br><br></div><div>Must add that I rarely say no to rnewman's requests because he is incredibly organized and thoughtful and seems to triple check everything before even considering bringing work onto a new branch.  <br><br></div><div>- Liz<br></div><div><br><br></div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Fri, Nov 20, 2015 at 11:22 AM, Gijs Kruitbosch <span dir="ltr"><<a href="mailto:gijskruitbosch@gmail.com" target="_blank">gijskruitbosch@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
I would like to propose that we eliminate the explicit aurora approval 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>
Why would this not cause horror and chaos:<br>
- I don't recall ever seeing this type of changes be denied aurora uplift;<br>
- I don't recall ever seeing this type of changes be backed out of aurora (but stay on m-c) after uplift because they broke the tree;<br>
- There would be no *obligation* to land changes on aurora (just the possibility to do so) - so if we refactor half the theme, engineers should be sensible enough not to uplift based just on this rule and either let things ride the train or request explicit approval;<br>
- We already effectively have test-only auto-approval for intermittent test fixes that worked on Nightly, so there is precedent that has been pretty problem-free to the best of my knowledge;<br>
<br>
Why do this?<br>
- Reduce process overhead. I don't think that the time I spend writing the approval requests and the time relman spends reviewing them is useful;<br>
- It would help streamline maintenance of the devedition theme, where we often don't find issues until right after merge day;<br>
- Reduce the time theme fixes take to reach general release audiences;<br>
- I have repeatedly seen mention that folks handling the approvals are overloaded, and this would lighten that burden a little, which would help with response time for other requests.<br>
<br>
<br>
How do people feel about this? Are there reasons not to do this that I've missed? Would people want to argue that there should be even fewer restrictions and/or are there other sets of changes that we could do this with?<br>
<br>
Gijs<br>
<br>
(please follow-up on firefox-dev)<br>
</blockquote></div><br><br clear="all"><br></div></div><span class="HOEnZb"><font color="#888888">-- <br><div><div dir="ltr"><div><div dir="ltr"><div><div>----<br></div>Liz Henry (:lizzard)<br></div><div>Firefox Release Manager<br></div><a href="mailto:lhenry@mozilla.com" target="_blank">lhenry@mozilla.com</a><br></div></div></div></div>
</font></span></div>
</blockquote></div><br></div>