(Citation levels: Dave - Julian - Dave - Julian)
[...] How does this approach compare to the one discussed in http://lists.boost.org/Archives/boost/2012/02/190418.php ?
The message above seems to be (mostly) describing a mechanism for automatically merging feature branches. As far as I can tell, the approaches are apples and oranges, and thus are basically compatible. We do something like that at Boostpro for handling upstream merges to Clang.
I'm not sure whether this is correct. The script I outlined does involve a git merge, but it's only a temporary one in the working directory that will be reset afterwards. The purpose of the script is not to merge (in fact the intent is to leave all branches unchanged) but to provide a transparent image to the testing volunteer, which includes exactly one branch of each Boost library.
Sorry, I don't understand what you mean by a "transparent image."
Oh. I think it was explained at the top of the message I pointed to, though. Basically the "testing image" is just a working copy of the (presumed monolithic) Boost tree, but not from one branch; most subdirectories come from the (super-project) develop branch, while others may come from any feature branch that the corresponding developers happened to "subscribe for testing". For a more complete explanation I think you could best just (re-)read the discussion that led up to that post, starting here: http://lists.boost.org/Archives/boost/2012/02/190269.php you could from there follow the bottom "Reply:" after every message, which will bring you to the end in 8 posts.
So my impression is that the planned Ryppl testing model and the testing model concept from the thread in the Boost archives do have similar goals, i.e. to automate testing of heterogeneous selections of branches from the various libraries. After some more thought I suspect the planned approach from Ryppl is superior, though. :-)
Why do you think that? (you give up pretty easily!)
Basically, from what you said the planned Ryppl approach seems more flexible: - developers can subscribe multiple branches to be tested instead of only one (which implicitly defaults to the develop branch); - there is a possibility to explicitly state which commit should be tested; - test slave owners can flexibly opt out of certain branches while still testing the other branches of the same library. I didn't mean to "give up", though. My proposed realisation of Thomas' idea is much simpler and seems more concrete. It's almost guaranteed to work given a "conservative" gitflow reincarnation of the current monolithic Boost tree. It might also work with a modularized Boost, in which case I'd consider it some kind of "primitive predecessor" of the planned Rypple testing model. But I didn't think very hard about the latter possibility. -Julian