<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Dec 15, 2015 at 11:18 AM, Jeremy Stanley <span dir="ltr"><<a href="mailto:fungi@yuggoth.org" target="_blank">fungi@yuggoth.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2015-12-15 08:30:20 -0600 (-0600), Kyle Mestery wrote:<br>
> This morning I tried to do two releases for networking sub-projects, and<br>
> both failed in slightly different ways.<br>
</span>[...]<br>
<br>
The goal of the merge-release-tags job is to provide a merge commit<br>
in review tying the new tag from a non-master branch history into<br>
the master branch history (but only if it's higher than the latest<br>
tag in master). In both cases here, the commit you tagged already<br>
appears in the master branch history, so there is nothing for the<br>
job to do. Unfortunately, its current failure mode in that situation<br>
seems to be to attempt to push the branch tip back up as a new<br>
change for review rather than aborting/skipping the push (which<br>
would make more sense).<br>
<br>
Anyway, it should be safe to ignore the failure results of the job<br>
in the two cases you linked, as the service it wanted to provide you<br>
was entirely unnecessary for these particular tags.<br>
<span class="HOEnZb"><font color="#888888">--<br></font></span></blockquote><div><br></div><div>Cool, thanks for the explanation Jeremy, that makes a lot of sense to me.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
Jeremy Stanley<br>
</font></span></blockquote></div><br></div></div>