<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, 13 Apr 2016 at 13:17 Zachary Ware <<a href="mailto:zachary.ware%2Bpydev@gmail.com">zachary.ware+pydev@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[SNIP]<br>
---<br>
<br>
After receiving a suggestion from koobs several months ago, I've been<br>
intermittently thinking about completely redoing our buildmaster setup<br>
such that instead of a single builder per version on each slave, we<br>
instead set up a series of builders with particular 'tags', and each<br>
builder attaches to each slave that satisfies the tags (running each<br>
build only on the first slave available).  This would allow us to test<br>
some of the rarer options (such as --without-threads) significantly<br>
more often than 'never', and generally get a lot more<br>
customization/flexibility of builds.  I haven't had a chance to sit<br>
down and think out all the edge cases of this idea, but what do people<br>
generally think of it?  I think the GitHub switchover will be a good<br>
time to do this if it's generally seen as a decent idea, since there<br>
will need to be some work on the buildmaster to do the switch anyway.<br></blockquote><div><br></div><div>So we have slaves connect to multiple builders who have requirements of what they are testing? So the --without-threads master would have all slaves able to compile --without-threads connect to it and then do that build? And those same slaves may also connect to the gcc and clang masters to do those builds as well? So would that mean slaves could potentially do a bunch of builds per change? That sounds nice to me as long as the slave maintainers are also up to utilizing this by double/triple/quadrupling their builds. </div></div></div>