On 10/05/2015 03:54 AM, Raffi Enficiaud wrote:
Le 04/10/15 15:37, Edward Diener a écrit :
On 10/04/2015 08:49 AM, Raffi Enficiaud wrote:
Le 04/10/15 13:38, John Maddock a écrit :
On 04/10/2015 12:09, Bjorn Reese wrote:
As many others have said, Boost.Test is "special" in that the majority of Boost's tests depend on it. Even breakages in develop are extremely painful in that they effectively halt progress for any Boost library which uses Test for testing.
Also special in the sense that boost.test cannot take full benefit from the current test dashboard setup: we have to test all libraries before being able to push to develop
Ideally yes, but in practicality you should be able to determine whether or not a change to Boost Test is working properly by only testing a very few libraries which you know use Boost Test's facilities extensively. Furthermore this situation will make absolutely no difference whether you use C++03 or C++11.
, which means hours and hours of testing and infrastructure deployment/maintenance for a single push to a branch that is supposed to help us develop boost.test. To be frank, I do not think that this requirement on boost.test makes sense.
First you claim a completely unreasonable practical requirement and then you say it makes no sense.
I thought it was your claim, but apparently you're saying that our test setup is not good enough, and the compilation of a subset of boost with our changes to develop should be part of the pre-push tests.
I am saying that your claim that Boost Test has to test all libraries before you push to 'develop' is an unreasonable practical requirement, and then you follow up by saying 'I do not think that this requirement on boost.test makes sense'. You yourself establish the requirement and then you complain of it as taking up too much time.
How easy it is to add tests from other libraries directly in boost.test tests? I am far from being a Bjam expert.
As for testing in C++03 mode - that's easy, just use GCC's default compiler mode ;-)
I have also a similar setup on OSX, but this does not prevent us from making mistakes, and capturing those mistakes before it goes to master is the very purpose of the develop branch.
What does what John suggested have to do with the 'develop' branch versus the 'master' branch ?
The problems that are arising in the ML are /only/ about the develop branch, mainly because sometimes we do not have the proper setup to catch some of the problems (MSVC8 for instance). According to the whole discussion thread here, boost.test is not supposed to make mistakes in the develop branch. OTOH, develop goes to master if and only if tests are ok, and only master is eligible for a release.
Nobody is arguing that making mistakes in the 'develop' branch does not occur. Gennady's response, however, was not that this was a mistake but a chosen decision to drop support for testing in anything other than C++11 mode. In other words he was saying that the change in 'develop' was not done by accident but done knowingly on purpose. Everybody is asking Boost Test to desist in the 'develop' branch from requiring libraries which use Boost Test to be compiled with C++11 support. Doing so can easily break the 'develop' test matrix for libraries which compile their tests in C++03 mode. John Maddock's comment about using gcc in it's default compiler mode of C++03 support was in response to your complaint that testing Boost Test using C++03 was a resource burden for Boost Test. But let's just move on. No one is seeking to lay blame on anyone for anything. Lots of libraries use Boost Test which need to be tested in C++03 mode so if Boost Test wants to move forward with a version which only supports testing in C++11 mode in order to use C++11 facilities, which is perfectly reasonable, it should do so as a separate library forked from the current version of Boost Test.
I do not see there anything not related to develop vs master, or the development workflow in general. Since according to you, I am missing something, please tell me why "develop vs. master" is off-topic.