<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, May 13, 2014 at 8:08 PM, Anthony Hughes <span dir="ltr"><<a href="mailto:ahughes@mozilla.com" target="_blank">ahughes@mozilla.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Okay, thanks for clarifying Gavin.<br>
<br>
To summarize what I think we've agreed to here:<br>
A) Near-merge landings that cannot be tested in time will ride the trains, carry over as part of the next iteration's workload, and possibly be backed out of a branch if QA finds serious issues.<br></blockquote><div>
<br></div><div>In general, yes. It's also possible that some "near-merge landings" will be delayed, for whatever reason, based on judgement of the involved engineers/designers/QA/release managers (though that should be exceptional, as Benjamin says).<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
B) Breakdown, UX polish, and Test-only bugs will be tagged [qa-] during work selection instead of first being tagged [qa?].<br></blockquote><br></div><div class="gmail_quote">I wouldn't limit it to "during work selection" - they should be tagged by anyone able to make the judgement, whenever that judgement can be made (e.g. could be when the bug is filed).<br>
<br></div><div class="gmail_quote">I've been meaning to start a separate discussion about the utility of [qa?]. Why not just assume all bugs assigned to an iteration need to be triaged and assigned qa+/qa- ?<br></div>
<div class="gmail_quote"><br></div><div class="gmail_quote">Gavin<br></div></div></div>