<div dir="ltr">There is good and meaningful comment here.  I will be meeting with the QA team to see if we can expose and continue to refine the process.  We are in the midst of finishing some reporting, which will help, as well as some documentation.  I have taken note of the suggestions for better messaging and reporting in general.<div><br></div><div>Best,</div><div>Wes</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 18, 2014 at 12:03 AM, John Meinel <span dir="ltr"><<a href="mailto:john@arbash-meinel.com" target="_blank">john@arbash-meinel.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>...</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
> 3. How do merges get unblocked?<br>
><br>
> Merges are unblocked when no bugs are returned with the above<br>
> criteria. The bugs should be updated only after the committed fix<br>
> has successfully passed the CI tests which discovered the<br>
> regression. This will most often mean setting the status to 'Fix<br>
> Released' when the solution involves code changes or removing the<br>
> regression and/or CI tag, if the issue is discovered to be a test<br>
> or CI issue.<br></div></div></blockquote><div><br></div></span><div>Note that being "just a test issue" doesn't entirely excuse it, because it means that the test suite will just fail again, and we won't have visibility into real problems. (We get into a mode where we expect the test suite to fail, and stop trusting it.)</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
><br>
><br>
> 4, If the unblock process involves manual steps, whose<br>
> responsibility is it to perform those steps?<br>
><br>
> The person or team that marked the bug as a regression is<br>
> responsible for updating the bug, once they are satisfied with the<br>
> fix. Most often this will be the Juju-QA team but if others<br>
> discover a regression they too should have the power to block<br>
> merges.<br>
<br>
</div></div>The problem often is nobody from QA is around to ask for help in<br>
certain times during the day. So there should be at least a person in<br>
each team knowing how (and having permissions as well, if needed) to<br>
re-run jobs that are stuck, mark the bug as Fix Released once the CI<br>
job passes after the fix lands. Another REALLY NEEDED feature is to<br>
re-queue PRs set for merging but bounced due to a CI block. This<br>
wastes days sometimes, or at the very least hours.<br>
<span><br></span></blockquote><div><br></div></span><div>One thing Tim mentioned was whether we could have the bot comment "I'm not merging this now because of a CI failure", but leave the request in the Queue, so it is automatically retried when the branch is unblocked. I'm not sure if there is an efficiency/event problem (we got an event that the $MERGE$ message was set, we wouldn't get another one unless someone pokes the branch.) But it does seem possible.</div><div><br></div><div>John</div><div>=:-></div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
><br>
><br>
> Based on experience and observation, I think I know how at least<br>
> some of this works but could we please have some authoritative<br>
> answers?<br>
><br>
> Thanks, Menno<br>
><br>
><br>
><br>
> -- Juju-dev mailing list <a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a><br>
</span>> <mailto:<a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a>> Modify settings or unsubscribe<br>
> at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
><br>
><br>
><br>
<br>
<br>
- --<br>
Dimiter Naydenov <<a href="mailto:dimiter.naydenov@canonical.com" target="_blank">dimiter.naydenov@canonical.com</a>><br>
juju-core team<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1<br>
<br>
iQEcBAEBAgAGBQJUkkBzAAoJENzxV2TbLzHwflIH+wQM8s8oV2i7b1PzsDzh9Zyu<br>
DhfkyIhxFQxTJGsV8RamcTDkjWeDhRZKB49UPzMdqNJr0XG/KvVy1SyqICxJ5qoz<br>
uWnnrdumzUhF0k/hjsUEnOpNDBOnubUIoGHBVyyx6UEMRgW+G0pFTIhUQGqEPhhU<br>
7YMqn/r3GpiSnkmnknB/U4yk9TEYViDBRuPzSmhJiSwBGqkpOW+ISkWstUgbqYO+<br>
o9KzxREWcvEDQ0+v0RLpaF2HsUWwktn7HL2BuoemhU4hoS5/ohD0VR5AemXwUyky<br>
ISEiqu4atjPcCxJts5UpPhhznBSVHFlOm4ROkH1ku+x671WZEZZXoUt4CjWbxvo=<br>
=l5mJ<br>
-----END PGP SIGNATURE-----<br>
<div><div><br>
--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
</div></div></blockquote></span></div></div></div>
<br>--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
<br></blockquote></div><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Wes Tapp<div>Juju QA & Release Manager</div></div></div>
</div>