Since this was turned on, here's the pulls that have automatically occurred.  Yay!

(2 others that I don't have the logs for, oops)
2013-11-15T22:14:32 -   calling github to merge D-Programming-Language/dmd/2773
2013-11-15T23:36:53 -   calling github to merge D-Programming-Language/dmd/2770
2013-11-16T00:58:58 -   calling github to merge D-Programming-Language/dmd/2778
2013-11-16T02:21:52 -   calling github to merge D-Programming-Language/dmd/2777
2013-11-16T03:27:19 -   calling github to merge D-Programming-Language/dmd/2765
2013-11-16T04:46:16 -   calling github to merge D-Programming-Language/dmd/2779
2013-11-16T10:26:06 -   calling github to merge D-Programming-Language/dmd/2781
2013-11-16T12:04:29 -   calling github to merge D-Programming-Language/dmd/2782

(Where's the phobos guys.. everyone asleep still?)

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:

  1) 5-ish platforms must have successfully re-built against the current master
  and
  2) all platforms must have successfully built with _a_ master + the current pull sha  (ie, results for out of date commits are ignored)

Too conservative still?  Not strict enough?

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:

  1) pending merges
  2) master branch
  3) other pulls

This will eliminate a good number of builds that cost considerable time, at the potential of not discovering a master break quite as quickly.

Give me your thoughts on both changes.

Thanks,
Brad

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

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.

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.


On Sun, Nov 17, 2013 at 7:33 AM, Brad Roberts <braddr@puremagic.com> wrote:

> Since this was turned on, here's the pulls that have automatically occurred.  Yay!
>
> (2 others that I don't have the logs for, oops)
> 2013-11-15T22:14:32 -   calling github to merge D-Programming-Language/dmd/
> 2773
> 2013-11-15T23:36:53 -   calling github to merge D-Programming-Language/dmd/
> 2770
> 2013-11-16T00:58:58 -   calling github to merge D-Programming-Language/dmd/
> 2778
> 2013-11-16T02:21:52 -   calling github to merge D-Programming-Language/dmd/
> 2777
> 2013-11-16T03:27:19 -   calling github to merge D-Programming-Language/dmd/
> 2765
> 2013-11-16T04:46:16 -   calling github to merge D-Programming-Language/dmd/
> 2779
> 2013-11-16T10:26:06 -   calling github to merge D-Programming-Language/dmd/
> 2781
> 2013-11-16T12:04:29 -   calling github to merge D-Programming-Language/dmd/
> 2782
>
> (Where's the phobos guys.. everyone asleep  still?)
>
> 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:
>
>   1) 5-ish platforms must have successfully re-built against the current
> master
>   and
>   2) all platforms must have successfully built with _a_ master + the
> current pull sha  (ie, results for out of date commits are ignored)
>
> Too conservative still?  Not strict enough?
>
> 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:
>
>   1) pending merges
>   2) master branch
>   3) other pulls
>
> This will eliminate a good number of builds that cost considerable time, at the potential of not discovering a master break quite as quickly.
>
> Give me your thoughts on both changes.
>
> Thanks,
> Brad
>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>