[SNIP]
---
After receiving a suggestion from koobs several months ago, I've been
intermittently thinking about completely redoing our buildmaster setup
such that instead of a single builder per version on each slave, we
instead set up a series of builders with particular 'tags', and each
builder attaches to each slave that satisfies the tags (running each
build only on the first slave available). This would allow us to test
some of the rarer options (such as --without-threads) significantly
more often than 'never', and generally get a lot more
customization/flexibility of builds. I haven't had a chance to sit
down and think out all the edge cases of this idea, but what do people
generally think of it? I think the GitHub switchover will be a good
time to do this if it's generally seen as a decent idea, since there
will need to be some work on the buildmaster to do the switch anyway.
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.