So this basically means that each library has to have its own testing farm, and Boost serves mostly the bundling purpose. A possible solution, I guess, but not sure such approach would be beneficial for the quality of Boost. I doubt that individual developers will be able to do the same amount of testing for their library releases as they had with svn.
how and when are things to be tested:
* when a commit is done to someLibrary/develop * when superproject/develop updates the submodule reference to someLibrary/develop?
If you're asking about my preferred approach then the first - when a commit is done to someLibrary/develop. And then again, when it is merged to someLibrary/master. No manual updates to the superproject are required.
i suppose that any other approach would ask for troubles. also, when testing someLibrary/develop it may depend on someOtherLibrary/develop. so if the tests would only run someLibrary/develop with all other dependent libraries checked out on master, one will run into troubles.
If I understood Daniel's suggestion, someLibrary/develop is never tested, except by the library developers or maybe free volunteers.
we are then loosing the biggest advantage of the testfarm: being able to see troubles early in the development process on platforms/toolchains the individual developer may not have access to. tim