<div dir="ltr">Changing the priority is a good idea, but I think we can only skip (or de-prioritize) the master build if the last merge was an auto-merge.  In that case we've essentially just run the exact same tests and can be sure they passed.  After a manual merge... history tells us that's not always the case.<div>
<br></div><div>As for the 'passed-at-one-point' auto-merge, this is probably fine.  Maybe add a limit to how old the old passing results can be?  I expect this won't be such a big problem if we have the prioritization.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Nov 17, 2013 at 7:33 AM, Brad Roberts <span dir="ltr"><<a href="mailto:braddr@puremagic.com" target="_blank">braddr@puremagic.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Since this was turned on, here's the pulls that have automatically occurred.  Yay!<br>
<br>
(2 others that I don't have the logs for, oops)<br>
2013-11-15T22:14:32 -   calling github to merge D-Programming-Language/dmd/<u></u>2773<br>
2013-11-15T23:36:53 -   calling github to merge D-Programming-Language/dmd/<u></u>2770<br>
2013-11-16T00:58:58 -   calling github to merge D-Programming-Language/dmd/<u></u>2778<br>
2013-11-16T02:21:52 -   calling github to merge D-Programming-Language/dmd/<u></u>2777<br>
2013-11-16T03:27:19 -   calling github to merge D-Programming-Language/dmd/<u></u>2765<br>
2013-11-16T04:46:16 -   calling github to merge D-Programming-Language/dmd/<u></u>2779<br>
2013-11-16T10:26:06 -   calling github to merge D-Programming-Language/dmd/<u></u>2781<br>
2013-11-16T12:04:29 -   calling github to merge D-Programming-Language/dmd/<u></u>2782<br>
<br>
(Where's the phobos guys.. everyone asleep  still?)<br>
<br>
Currently the pace of merging is bottle necked by the slowest platform, the freebsd's.  The current merge criteria is that all platforms must successfully complete a run.  I'm considering changing that to something a little less conservative, like:<br>

<br>
  1) 5-ish platforms must have successfully re-built against the current master<br>
  and<br>
  2) all platforms must have successfully built with _a_ master + the current pull sha  (ie, results for out of date commits are ignored)<br>
<br>
Too conservative still?  Not strict enough?<br>
<br>
I'm also considering a build ordering change.  Right now master branch build have priority over pull builds.  What do you guys think about moving the priority to:<br>
<br>
  1) pending merges<br>
  2) master branch<br>
  3) other pulls<br>
<br>
This will eliminate a good number of builds that cost considerable time, at the potential of not discovering a master break quite as quickly.<br>
<br>
Give me your thoughts on both changes.<br>
<br>
Thanks,<br>
Brad<br>
<br>
______________________________<u></u>_________________<br>
dmd-internals mailing list<br>
<a href="mailto:dmd-internals@puremagic.com" target="_blank">dmd-internals@puremagic.com</a><br>
<a href="http://lists.puremagic.com/mailman/listinfo/dmd-internals" target="_blank">http://lists.puremagic.com/<u></u>mailman/listinfo/dmd-internals</a><br>
</blockquote></div><br></div>