<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"><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>-- <br><div class="gmail_signature"><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>
</div>