<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 22, 2015 at 9:52 PM, Axel Hecht <span dir="ltr"><<a href="mailto:l10n@mozilla.com" target="_blank">l10n@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 bgcolor="#FFFFFF" text="#000000">
Here's a few observations of mine:<br>
<br>
I only see a very limited set of patches trying to get uplifted.
Which means that most folks probably do a pretty good judgement on
whether they should uplift or not.</div></blockquote><div><br></div><div>I don't believe that this follows at all. Good judgement includes not only of saying</div><div>no to things that shouldn't be uplifted, but also saying yes to things that shouldl.</div><div><br></div><div>Say that out of 1000 patches, 50 should probably get uplifted, but people apply</div><div>really high standards and so only the best 5 get uplifted. That's bad judgement</div><div>not good.</div><div> </div><div>-Ekr</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
I see very few patches that request uplift that shouldn't. Mostly
because people don't understand the tree rules in detail.<br>
<br>
Thus, if we make exceptions, we should only make those that we
ensure by an hg hook that validates that patches as landed stick to
the rules. An existing example is the l10n-approval hook, which only
exists because developers said "No string changes in this patch"
wrongly too often.<br>
<br>
That said, something like the devtools theme sounds like a good
candidate for an exception.<br>
<br>
I've also pondered whether all approvals need to be done by relman,
or if there's a set of engineers that can help with those requests.<br>
OTH, relman also wants to get more involved in Nightly, I heard.
Those two probably build one context to look at.<span class="HOEnZb"><font color="#888888"><br>
<br>
Axel</font></span><div><div class="h5"><br>
<br>
<div>On 11/21/15 1:19 AM, Richard Newman
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">I think I'm with cpeterson on this. Three cents:
<div>
<ol>
<li>My experience has been that, if I want to, I can write
an approval request that is persuasive enough to land just
about anything in Aurora.</li>
<li>I'd rather have developers take an extra week to get
something right, and uplift it to early Aurora with module
peer approval, than rush to get changes in just before a
merge to avoid having to go through the uplift approval
process. Higher quality, less stress.</li>
<li>I would tentatively assert that the primary reason we
don't get more bustage from uplifts is because of
developers not asking to uplift risky changes, rather than
approvals being denied.</li>
</ol>
<div>In short: I'm in favor of removing process where it has
more cost than benefit.</div>
</div>
<div><br>
</div>
<div>(Obviously the localization process still plays in here, so
it's not a total free-for-all.)</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Nov 20, 2015 at 11:34 AM, Chris
Peterson <span dir="ltr"><<a href="mailto:cpeterson@mozilla.com" target="_blank">cpeterson@mozilla.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">How often
are Aurora uplifts denied for other types of code changes
(C++ or JS)?<br>
<br>
Why not allow any code change to be uplifted to Aurora based
on the developer's discretion? Or allow a patch's reviewer
to a+ for Aurora uplift?
<div>
<div><br>
<br>
<br>
<br>
On 11/20/15 11:22 AM, Gijs Kruitbosch 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>
_______________________________________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org" target="_blank">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>
</blockquote>
<br>
_______________________________________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org" target="_blank">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>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
firefox-dev mailing list
<a href="mailto:firefox-dev@mozilla.org" target="_blank">firefox-dev@mozilla.org</a>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" target="_blank">https://mail.mozilla.org/listinfo/firefox-dev</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<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></blockquote></div><br></div></div>