on Mon Dec 17 2012, Julian Gonggrijp <j.gonggrijp-AT-gmail.com> wrote:
Dave Abrahams wrote:
on Sun Dec 16 2012, "Peter Dimov" wrote:
I wonder how testing will work. Will the "develop" and "master" branches of each repo be tested?
What's going to be tested is fluid. The ultimate goal is to allow developers to request specific combinations of tests with each commit by modifying a .json file in their project's root directory. In the meantime, I expect to test every commit on any branch.
Wouldn't the latter be a giant amount of work for the testers?
No, it will happen automatically. Testers aren't going to have to intercede.
I do subscribe to the idea that testing should be configurable by the developers. I'm not sure whether a file that is subject to version control would be a wise way to provide for that configurability.
We've thought it through for years and IMO it's an extremely attractive option. Having a record of exactly what was tested alongside the commit seems like a good idea to me. What is your objection?
Not all testing should be optional, I think;
Of course not.
form my understanding of the purpose of the test infrastructure it seems that the temporary release branches (gitflow style) should always be tested.
Sure.
The biggest question is against which versions of Boost dependencies the commit will be tested. The obvious choices are 1. the version that was part of the last boost release, and 2. the last version of the dependency to be individually released (i.e. that dependency's "master" branch).
Feedback/opinions on that choice are most welcome.
Definitely option 2, conflicts are likely to be found sooner in that way.
The downside of that approach is that one library developer creating a broken individual release may break testing for all other libraries, causing general instability and upset. That is currently the case for many people with trunk testing today, and some of us have been arguing for a long while that it would be better to do most testing against the last stable release of a library. Presumably that effect would be somewhat mitigated by testing against only *releases* of individual library dependencies, but it would not be entirely eliminated. We can avoid this problem by allowing developers to decide which version of individual dependencies they want to test against. In general one might want to stick with the last released Boost version, but occasionally one might need features developed during the current Boost release cycle, in which case the .json file could specify a later revision. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost