What are the things that we HAVE TO fix before shipping 1.56.0?
We’re coming down to the end of the release process, so I’m taking a poll. * What bugs do you think MUST be fixed before shipping 1.56? In other words, if bug XXX is not fixed, then (in your opinion) we should not bother making a release. Thanks in advance. — Marshall
On 28 Jul 2014 at 14:24, Marshall Clow wrote:
We´re coming down to the end of the release process, so I´m taking a poll.
* What bugs do you think MUST be fixed before shipping 1.56? In other words, if bug XXX is not fixed, then (in your opinion) we should not bother making a release.
I have proposed Boost.AFIO building and passing all unit soak tests on: GCCs 4.6 to 4.9, x86, x64 and ARMv7a. clangs 3.2 to 3.4, x86, x64. ARMv7a fails, but I don't think that is Boost's fault. MSVCs 11 and 12, x86, x64. The is a good test that AFIO's dependencies ASIO, Thread, Chrono, Filesytem are all strong in 1.56 under very heavy multithreaded usage. What is currently failing is MSVC 10 (VS2010) in C++0x build mode. AFIO has not changed since Boost 1.55, so something has changed in 1.56. It is something to do with the scoped enum emulation, what used to work no longer works in VS2010 on 1.56. I don't think this is a showstopper though, I am currently working around it with new code. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 7/28/2014 6:03 PM, Niall Douglas wrote:
On 28 Jul 2014 at 14:24, Marshall Clow wrote:
We´re coming down to the end of the release process, so I´m taking a poll.
* What bugs do you think MUST be fixed before shipping 1.56? In other words, if bug XXX is not fixed, then (in your opinion) we should not bother making a release.
I have proposed Boost.AFIO building and passing all unit soak tests on:
GCCs 4.6 to 4.9, x86, x64 and ARMv7a.
clangs 3.2 to 3.4, x86, x64. ARMv7a fails, but I don't think that is Boost's fault.
MSVCs 11 and 12, x86, x64.
The is a good test that AFIO's dependencies ASIO, Thread, Chrono, Filesytem are all strong in 1.56 under very heavy multithreaded usage.
What is currently failing is MSVC 10 (VS2010) in C++0x build mode. AFIO has not changed since Boost 1.55, so something has changed in 1.56. It is something to do with the scoped enum emulation, what used to work no longer works in VS2010 on 1.56.
Can you trace this to something in one of the Boost libraries AFIO uses ? If so that issue might need to be addressed for 1.56.
I don't think this is a showstopper though, I am currently working around it with new code.
On 28 Jul 2014 at 19:32, Edward Diener wrote:
What is currently failing is MSVC 10 (VS2010) in C++0x build mode. AFIO has not changed since Boost 1.55, so something has changed in 1.56. It is something to do with the scoped enum emulation, what used to work no longer works in VS2010 on 1.56.
Can you trace this to something in one of the Boost libraries AFIO uses ? If so that issue might need to be addressed for 1.56.
I figured out the cause - up until now the code just happened to work by accident under 32 bit, and I only had a WinXP CI test slave before. Under 64 bit it breaks as it should have done since the beginning. So, we can scratch this problem, it was AFIO at fault. I look more forward every day to when VS2014 comes out and I can drop VS2010 support like a stone. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Marshall Clow wrote:
We’re coming down to the end of the release process, so I’m taking a poll.
* What bugs do you think MUST be fixed before shipping 1.56? In other words, if bug XXX is not fixed, then (in your opinion) we should not bother making a release.
It's not a showstopper but the regression results still aren't displayed for Geometry master (after the addition of sublibs file): http://www.boost.org/development/tests/master/developer/geometry.html We can see the results for develop and run tests locally but we can't do as extensive testing as it's done by the volunteers. We wrote about it on Boost and Boost-Testing lists more than a month ago but nobody answered. We also tried to contact one of the runners to re-run some tests, it didn't help. With the tests missing I can't fully answer your question. Regards, Adam
On Jul 28, 2014, at 5:36 PM, Adam Wulkiewicz <adam.wulkiewicz@gmail.com> wrote:
Marshall Clow wrote:
We’re coming down to the end of the release process, so I’m taking a poll.
* What bugs do you think MUST be fixed before shipping 1.56? In other words, if bug XXX is not fixed, then (in your opinion) we should not bother making a release.
It's not a showstopper but the regression results still aren't displayed for Geometry master (after the addition of sublibs file): http://www.boost.org/development/tests/master/developer/geometry.html We can see the results for develop and run tests locally but we can't do as extensive testing as it's done by the volunteers.
We wrote about it on Boost and Boost-Testing lists more than a month ago but nobody answered. We also tried to contact one of the runners to re-run some tests, it didn't help. With the tests missing I can't fully answer your question.
I just made a change to see if I can get Geometry on master to work. With luck, our testers should post results in a bit. — Noel
Kenneth Belcourt wrote:
On Jul 28, 2014, at 5:36 PM, Adam Wulkiewicz <adam.wulkiewicz@gmail.com> wrote:
It's not a showstopper but the regression results still aren't displayed for Geometry master (after the addition of sublibs file): http://www.boost.org/development/tests/master/developer/geometry.html We can see the results for develop and run tests locally but we can't do as extensive testing as it's done by the volunteers.
We wrote about it on Boost and Boost-Testing lists more than a month ago but nobody answered. We also tried to contact one of the runners to re-run some tests, it didn't help. With the tests missing I can't fully answer your question. I just made a change to see if I can get Geometry on master to work. With luck, our testers should post results in a bit.
Thanks! Some of the testers rerun the tests already but the situation stays the same. Or should we wait for all of the testers to see the result of your changes? Regards, Adam
On Jul 30, 2014, at 4:51 AM, Adam Wulkiewicz <adam.wulkiewicz@gmail.com> wrote:
Kenneth Belcourt wrote:
On Jul 28, 2014, at 5:36 PM, Adam Wulkiewicz <adam.wulkiewicz@gmail.com> wrote:
It's not a showstopper but the regression results still aren't displayed for Geometry master (after the addition of sublibs file): http://www.boost.org/development/tests/master/developer/geometry.html We can see the results for develop and run tests locally but we can't do as extensive testing as it's done by the volunteers.
We wrote about it on Boost and Boost-Testing lists more than a month ago but nobody answered. We also tried to contact one of the runners to re-run some tests, it didn't help. With the tests missing I can't fully answer your question. I just made a change to see if I can get Geometry on master to work. With luck, our testers should post results in a bit.
Some of the testers rerun the tests already but the situation stays the same. Or should we wait for all of the testers to see the result of your changes?
The changes I made were just to our local testers. Frankly, I have no idea why geometry doesn’t show up in master, I’ll try to debug this a bit more this evening.
Hi, Op 30 jul. 2014 om 20:08 heeft "Belcourt, Kenneth" <kbelco@sandia.gov> het volgende geschreven:
On Jul 30, 2014, at 4:51 AM, Adam Wulkiewicz <adam.wulkiewicz@gmail.com> wrote:
Kenneth Belcourt wrote:
On Jul 28, 2014, at 5:36 PM, Adam Wulkiewicz <adam.wulkiewicz@gmail.com> wrote:
It's not a showstopper but the regression results still aren't displayed for Geometry master (after the addition of sublibs file): http://www.boost.org/development/tests/master/developer/geometry.html We can see the results for develop and run tests locally but we can't do as extensive testing as it's done by the volunteers.
We wrote about it on Boost and Boost-Testing lists more than a month ago but nobody answered. We also tried to contact one of the runners to re-run some tests, it didn't help. With the tests missing I can't fully answer your question. I just made a change to see if I can get Geometry on master to work. With luck, our testers should post results in a bit.
Some of the testers rerun the tests already but the situation stays the same. Or should we wait for all of the testers to see the result of your changes?
The changes I made were just to our local testers. Frankly, I have no idea why geometry doesn’t show up in master, I’ll try to debug this a bit more this evening.
Thanks. For Boost.Spirit it seems to be the same. No results on master, but on certain platforms (those of j.c. bell), there are results (July 25). The same as Geometry. Regards, Barend
Barend Gehrels wrote:
Op 30 jul. 2014 om 20:08 heeft "Belcourt, Kenneth" <kbelco@sandia.gov> het volgende geschreven:
On Jul 30, 2014, at 4:51 AM, Adam Wulkiewicz <adam.wulkiewicz@gmail.com> wrote:
Kenneth Belcourt wrote:
On Jul 28, 2014, at 5:36 PM, Adam Wulkiewicz <adam.wulkiewicz@gmail.com> wrote:
It's not a showstopper but the regression results still aren't displayed for Geometry master (after the addition of sublibs file): http://www.boost.org/development/tests/master/developer/geometry.html We can see the results for develop and run tests locally but we can't do as extensive testing as it's done by the volunteers.
We wrote about it on Boost and Boost-Testing lists more than a month ago but nobody answered. We also tried to contact one of the runners to re-run some tests, it didn't help. With the tests missing I can't fully answer your question. I just made a change to see if I can get Geometry on master to work. With luck, our testers should post results in a bit. Some of the testers rerun the tests already but the situation stays the same. Or should we wait for all of the testers to see the result of your changes? The changes I made were just to our local testers. Frankly, I have no idea why geometry doesn’t show up in master, I’ll try to debug this a bit more this evening.
Thanks.
For Boost.Spirit it seems to be the same. No results on master, but on certain platforms (those of j.c. bell), there are results (July 25). The same as Geometry.
Interesting, in this case sublibs file was added 4 years ago. So either nobody noticed that tests are missing for 4 years or something else causes the problem. Assuming that it wasn't merged in master recently, or was it? AFAIR there was some change in Config(?) made some time ago which also caused some problems with missing tests, e.g. in Geometry and Math. But this should be fixed now, it works in develop. May it be somehow related? When I run: b2 --dump-tests status/ the tests are listed. And AFAIR the results are sent to the server with logs and everything. So I'm guessing that it's something wrong on the server-side or it's a bug in the Regression, assuming that the scripts/program generating the HTML results from XMLs sent by the runners is in this module. Should I create a ticket or do you have some other ideas? Regards, Adam
On Jul 30, 2014, at 5:14 PM, Adam Wulkiewicz <adam.wulkiewicz@gmail.com> wrote:
Barend Gehrels wrote:
Op 30 jul. 2014 om 20:08 heeft "Belcourt, Kenneth" <kbelco@sandia.gov> het volgende geschreven:
On Jul 30, 2014, at 4:51 AM, Adam Wulkiewicz <adam.wulkiewicz@gmail.com> wrote:
Kenneth Belcourt wrote:
On Jul 28, 2014, at 5:36 PM, Adam Wulkiewicz <adam.wulkiewicz@gmail.com> wrote:
It's not a showstopper but the regression results still aren't displayed for Geometry master (after the addition of sublibs file): http://www.boost.org/development/tests/master/developer/geometry.html We can see the results for develop and run tests locally but we can't do as extensive testing as it's done by the volunteers.
We wrote about it on Boost and Boost-Testing lists more than a month ago but nobody answered. We also tried to contact one of the runners to re-run some tests, it didn't help. With the tests missing I can't fully answer your question. I just made a change to see if I can get Geometry on master to work. With luck, our testers should post results in a bit. Some of the testers rerun the tests already but the situation stays the same. Or should we wait for all of the testers to see the result of your changes? The changes I made were just to our local testers. Frankly, I have no idea why geometry doesn’t show up in master, I’ll try to debug this a bit more this evening.
Thanks.
For Boost.Spirit it seems to be the same. No results on master, but on certain platforms (those of j.c. bell), there are results (July 25). The same as Geometry.
Interesting, in this case sublibs file was added 4 years ago. So either nobody noticed that tests are missing for 4 years or something else causes the problem. Assuming that it wasn't merged in master recently, or was it?
AFAIR there was some change in Config(?) made some time ago which also caused some problems with missing tests, e.g. in Geometry and Math. But this should be fixed now, it works in develop. May it be somehow related?
When I run: b2 --dump-tests status/ the tests are listed. And AFAIR the results are sent to the server with logs and everything.
So I'm guessing that it's something wrong on the server-side or it's a bug in the Regression, assuming that the scripts/program generating the HTML results from XMLs sent by the runners is in this module. Should I create a ticket or do you have some other ideas?
The tests are in the tester composite xml file (e.g. Sandia-gcc-4.8.2.xml) so they’re getting built and trying to run. Why they don’t show up in html could be that test-type and test-program in the xml test-log are both blank. <test-log library="geometry/test" test-name="access" test-type="" test-program="" target-directory="boost/bin.v2/libs/geometry/test/core/access.test/gcc-4.8.2/debug" toolset="gcc-4.8.2" show-run-output="true”> So I went back and looked in the test results/bjam.log and found this: testing.capture-output /scratch/boost_testing/results/boost/bin.v2/libs/geometry/test/core/access.test/gcc-4.8.2/debug/access.run LD_LIBRARY_PATH="/sierra/sntools/SDK/compilers/gcc/4.8.2-RHEL6/bin:/sierra/sntools/SDK/compilers/gcc/4.8.2-RHEL6/lib:/sierra/sntools/SDK/compilers/gcc/4.8.2-RHEL6/lib32:/sierra/sntools/SDK/compilers/gcc/4.8.2-RHEL6/lib64:$LD_LIBRARY_PATH" export LD_LIBRARY_PATH status=0 if test $status -ne 0 ; then echo Skipping test execution due to testing.execute=off exit 0 fi Why is testing.execute is off? Can you in master turn off all tests in geometry/test except for, say, core. And perhaps all tests in core/Jamfile.v2 except for the access test and let tests cycle to see if that one test will run? Maybe b2’s memory is getting thrashed? — Noel
Kenneth Belcourt wrote:
On Jul 30, 2014, at 5:14 PM, Adam Wulkiewicz <adam.wulkiewicz@gmail.com> wrote:
Barend Gehrels wrote:
For Boost.Spirit it seems to be the same. No results on master, but on certain platforms (those of j.c. bell), there are results (July 25). The same as Geometry. Interesting, in this case sublibs file was added 4 years ago. So either nobody noticed that tests are missing for 4 years or something else causes the problem. Assuming that it wasn't merged in master recently, or was it?
AFAIR there was some change in Config(?) made some time ago which also caused some problems with missing tests, e.g. in Geometry and Math. But this should be fixed now, it works in develop. May it be somehow related?
When I run: b2 --dump-tests status/ the tests are listed. And AFAIR the results are sent to the server with logs and everything.
So I'm guessing that it's something wrong on the server-side or it's a bug in the Regression, assuming that the scripts/program generating the HTML results from XMLs sent by the runners is in this module. Should I create a ticket or do you have some other ideas? The tests are in the tester composite xml file (e.g. Sandia-gcc-4.8.2.xml) so they’re getting built and trying to run. Why they don’t show up in html could be that test-type and test-program in the xml test-log are both blank.
<test-log library="geometry/test" test-name="access" test-type="" test-program="" target-directory="boost/bin.v2/libs/geometry/test/core/access.test/gcc-4.8.2/debug" toolset="gcc-4.8.2" show-run-output="true”>
Is this true only for Geometry (and Spirit)?
So I went back and looked in the test results/bjam.log and found this:
testing.capture-output /scratch/boost_testing/results/boost/bin.v2/libs/geometry/test/core/access.test/gcc-4.8.2/debug/access.run
LD_LIBRARY_PATH="/sierra/sntools/SDK/compilers/gcc/4.8.2-RHEL6/bin:/sierra/sntools/SDK/compilers/gcc/4.8.2-RHEL6/lib:/sierra/sntools/SDK/compilers/gcc/4.8.2-RHEL6/lib32:/sierra/sntools/SDK/compilers/gcc/4.8.2-RHEL6/lib64:$LD_LIBRARY_PATH" export LD_LIBRARY_PATH
status=0 if test $status -ne 0 ; then echo Skipping test execution due to testing.execute=off exit 0 fi
Why is testing.execute is off?
Isn't it just some script which somewhere later should display/output this 'Skipping...' message and exit if status were not equal to 0 (probably meaning that the test wasn't built properly or something similar)? If the above is true I'm guessing that it should be in the log for all libraries.
Can you in master turn off all tests in geometry/test except for, say, core. And perhaps all tests in core/Jamfile.v2 except for the access test and let tests cycle to see if that one test will run? Maybe b2’s memory is getting thrashed?
I'm not sure if we can do this now. AFAIK the master branch is currently closed. Regards, Adam
* What bugs do you think MUST be fixed before shipping 1.56? In other words, if bug XXX is not fixed, then (in your opinion) we should not bother making a release.
There is one crippling bug with graph library that probably only affects me since I could not find anyone else being bothered by it.
Anyway I proposed a fix a few weeks ago but had no answer, I really think it should be fixed in the next release since it completely breaks graph library with visual studio 2013. The bug I filed is here, along with my proposed correction: https://svn.boost.org/trac/boost/ticket/10165 Ernest Galbrun.
On Tue, Jul 29, 2014 at 1:24 AM, Marshall Clow <mclow.lists@gmail.com> wrote:
We’re coming down to the end of the release process, so I’m taking a poll.
* What bugs do you think MUST be fixed before shipping 1.56? In other words, if bug XXX is not fixed, then (in your opinion) we should not bother making a release.
I think the issue in the nearby thread [1] needs to be fixed before the release. The fix is rather simple anyway. [1] http://lists.boost.org/Archives/boost/2014/07/215581.php
On 7/29/2014 12:32 AM, Andrey Semashev wrote:
On Tue, Jul 29, 2014 at 1:24 AM, Marshall Clow <mclow.lists@gmail.com> wrote:
We’re coming down to the end of the release process, so I’m taking a poll.
* What bugs do you think MUST be fixed before shipping 1.56? In other words, if bug XXX is not fixed, then (in your opinion) we should not bother making a release.
I think the issue in the nearby thread [1] needs to be fixed before the release. The fix is rather simple anyway.
[1] http://lists.boost.org/Archives/boost/2014/07/215581.php
Did you/someone file a bug? It's unlikely to get fixed otherwise.
On 7/29/2014 8:18 AM, Eric Niebler wrote:
On 7/29/2014 12:32 AM, Andrey Semashev wrote:
On Tue, Jul 29, 2014 at 1:24 AM, Marshall Clow <mclow.lists@gmail.com> wrote:
We’re coming down to the end of the release process, so I’m taking a poll.
* What bugs do you think MUST be fixed before shipping 1.56? In other words, if bug XXX is not fixed, then (in your opinion) we should not bother making a release.
I think the issue in the nearby thread [1] needs to be fixed before the release. The fix is rather simple anyway.
[1] http://lists.boost.org/Archives/boost/2014/07/215581.php
Did you/someone file a bug? It's unlikely to get fixed otherwise.
Sorry, I see the pull request now.[*] I agree, it'd be nice to have this fix, but I'm not anxious to hold up the release. Marshall? Can you point me to the operator overload in Boost.Range that is causing this problem? The longer-term fix is to be smarter there. Eric [*] https://github.com/boostorg/asio/pull/7
On Tuesday 29 July 2014 08:31:55 Eric Niebler wrote:
Can you point me to the operator overload in Boost.Range that is causing this problem? The longer-term fix is to be smarter there.
All operators for iterator_range are potential sources of the problem, see boost/range/iterator_range_core.hpp:537 and below. In this particular case it was operator<. I've created a ticket [1] suggesting to move all Boost.Range components into its own namespace. [1] https://svn.boost.org/trac/boost/ticket/10269
On Jul 29, 2014, at 8:31 AM, Eric Niebler <eniebler@boost.org> wrote:
On 7/29/2014 8:18 AM, Eric Niebler wrote:
On 7/29/2014 12:32 AM, Andrey Semashev wrote:
On Tue, Jul 29, 2014 at 1:24 AM, Marshall Clow <mclow.lists@gmail.com> wrote:
We’re coming down to the end of the release process, so I’m taking a poll.
* What bugs do you think MUST be fixed before shipping 1.56? In other words, if bug XXX is not fixed, then (in your opinion) we should not bother making a release.
I think the issue in the nearby thread [1] needs to be fixed before the release. The fix is rather simple anyway.
[1] http://lists.boost.org/Archives/boost/2014/07/215581.php
Did you/someone file a bug? It's unlikely to get fixed otherwise.
Sorry, I see the pull request now.[*] I agree, it'd be nice to have this fix, but I'm not anxious to hold up the release. Marshall?
I’m really leery of putting something in the release that hasn’t gone through a test cycle. — Marshall
On 07/29/2014 01:36 PM, Marshall Clow wrote:
On Jul 29, 2014, at 8:31 AM, Eric Niebler <eniebler@boost.org> wrote:
On 7/29/2014 8:18 AM, Eric Niebler wrote:
On 7/29/2014 12:32 AM, Andrey Semashev wrote:
On Tue, Jul 29, 2014 at 1:24 AM, Marshall Clow <mclow.lists@gmail.com> wrote:
We’re coming down to the end of the release process, so I’m taking a poll.
* What bugs do you think MUST be fixed before shipping 1.56? In other words, if bug XXX is not fixed, then (in your opinion) we should not bother making a release.
I think the issue in the nearby thread [1] needs to be fixed before the release. The fix is rather simple anyway.
[1] http://lists.boost.org/Archives/boost/2014/07/215581.php
Did you/someone file a bug? It's unlikely to get fixed otherwise.
Sorry, I see the pull request now.[*] I agree, it'd be nice to have this fix, but I'm not anxious to hold up the release. Marshall?
I’m really leery of putting something in the release that hasn’t gone through a test cycle.
Naturally. But see [1] for another case where this is a problem. It looks bad. We have two choices: 1) Hold up the release while we work on a fix and run some emergency tests. 2) Release as-is, then quickly roll a point release. The fact that two people have reported the issue separately gives me pause. Eric [1]: https://groups.google.com/d/msg/boost-developers-archive/6JVNg7ZPb4k/RAlvPUe...
On 7/29/2014 3:39 PM, Eric Niebler wrote:
On 07/29/2014 01:36 PM, Marshall Clow wrote:
On Jul 29, 2014, at 8:31 AM, Eric Niebler <eniebler@boost.org> wrote:
On 7/29/2014 8:18 AM, Eric Niebler wrote:
On 7/29/2014 12:32 AM, Andrey Semashev wrote:
On Tue, Jul 29, 2014 at 1:24 AM, Marshall Clow <mclow.lists@gmail.com> wrote:
We’re coming down to the end of the release process, so I’m taking a poll.
* What bugs do you think MUST be fixed before shipping 1.56? In other words, if bug XXX is not fixed, then (in your opinion) we should not bother making a release.
I think the issue in the nearby thread [1] needs to be fixed before the release. The fix is rather simple anyway.
[1] http://lists.boost.org/Archives/boost/2014/07/215581.php
Did you/someone file a bug? It's unlikely to get fixed otherwise.
Sorry, I see the pull request now.[*] I agree, it'd be nice to have this fix, but I'm not anxious to hold up the release. Marshall?
I’m really leery of putting something in the release that hasn’t gone through a test cycle.
Naturally. But see [1] for another case where this is a problem. It looks bad. We have two choices:
1) Hold up the release while we work on a fix and run some emergency tests. 2) Release as-is, then quickly roll a point release.
The fact that two people have reported the issue separately gives me pause.
Eric
[1]: https://groups.google.com/d/msg/boost-developers-archive/6JVNg7ZPb4k/RAlvPUe...
More information, cc'ing Neil. The problem is this commit is Boost.Range: https://github.com/boostorg/range/commit/1d91272a551df2cd1776d6447c0e39a14f6... The change to the free relational operators is causing havoc. The fix should be as simple as reverting to the 1.55 formulation of them. I'll send a patch shortly. Neil, please chime in ASAP if you think that's the wrong fix. Eric
On Jul 29, 2014, at 3:59 PM, Eric Niebler <eniebler@boost.org> wrote:
On 7/29/2014 3:39 PM, Eric Niebler wrote:
On 07/29/2014 01:36 PM, Marshall Clow wrote:
On Jul 29, 2014, at 8:31 AM, Eric Niebler <eniebler@boost.org> wrote:
On 7/29/2014 8:18 AM, Eric Niebler wrote:
On 7/29/2014 12:32 AM, Andrey Semashev wrote:
On Tue, Jul 29, 2014 at 1:24 AM, Marshall Clow <mclow.lists@gmail.com> wrote: > We’re coming down to the end of the release process, so I’m taking a poll. > > * What bugs do you think MUST be fixed before shipping 1.56? > In other words, if bug XXX is not fixed, then (in your opinion) we should not bother making a release.
I think the issue in the nearby thread [1] needs to be fixed before the release. The fix is rather simple anyway.
[1] http://lists.boost.org/Archives/boost/2014/07/215581.php
Did you/someone file a bug? It's unlikely to get fixed otherwise.
Sorry, I see the pull request now.[*] I agree, it'd be nice to have this fix, but I'm not anxious to hold up the release. Marshall?
I’m really leery of putting something in the release that hasn’t gone through a test cycle.
Naturally. But see [1] for another case where this is a problem. It looks bad. We have two choices:
1) Hold up the release while we work on a fix and run some emergency tests. 2) Release as-is, then quickly roll a point release.
The fact that two people have reported the issue separately gives me pause.
Eric
[1]: https://groups.google.com/d/msg/boost-developers-archive/6JVNg7ZPb4k/RAlvPUe...
More information, cc'ing Neil.
The problem is this commit is Boost.Range:
https://github.com/boostorg/range/commit/1d91272a551df2cd1776d6447c0e39a14f6...
The change to the free relational operators is causing havoc. The fix should be as simple as reverting to the 1.55 formulation of them. I'll send a patch shortly.
Neil, please chime in ASAP if you think that's the wrong fix.
Let’s get this checked into Boost.Range, and watch the tests. [ And people can run their own tests, too ] — Marshall
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Marshall Clow Sent: 28 July 2014 22:25 To: boost@lists.boost.org List Subject: [boost] What are the things that we HAVE TO fix before shipping 1.56.0?
We're coming down to the end of the release process, so I'm taking a poll.
* What bugs do you think MUST be fixed before shipping 1.56? In other words, if bug XXX is not fixed, then (in your opinion) we should not bother making a release.
IMO - None - I feel we need to get a release out asap, warts and all. Those terminally inconvenienced can use GIT to get fixes from master or develop. And we should expect to follow with a 1.56.1 bugfix pretty soon (and 1.56.2 as well?). We should save new things for 1.57. Paul PS I'm aware that this means more work for you Marshall - for which many thanks. But wasn't the whole idea was to release more often? --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
Paul A. Bristow <pbristow <at> hetp.u-net.com> writes:
-----Original Message----- From: Boost [mailto:boost-bounces <at> lists.boost.org] On Behalf Of
Marshall Clow
Sent: 28 July 2014 22:25 To: boost <at> lists.boost.org List Subject: [boost] What are the things that we HAVE TO fix before shipping 1.56.0?
We're coming down to the end of the release process, so I'm taking a poll.
* What bugs do you think MUST be fixed before shipping 1.56? In other words, if bug XXX is not fixed, then (in your opinion) we should not bother making a release.
IMO - None - I feel we need to get a release out asap, warts and all.
Those terminally inconvenienced can use GIT to get fixes from master or develop.
Seconded. It's time to get a payoff from the modularization effort in terms of per-lib quickfixes. And, as a community, we need to learn how to take advantage of this new capability, communicate inter-release drops, etc. Joaquín M López Muñoz Telefónica
On Mon, 28 Jul 2014 14:24:52 -0700 Marshall Clow <mclow.lists@gmail.com> wrote:
We’re coming down to the end of the release process, so I’m taking a poll.
* What bugs do you think MUST be fixed before shipping 1.56? In other words, if bug XXX is not fixed, then (in your opinion) we should not bother making a release.
Not sure if this is a show-stopper or not, but property_tree API was broken a little. My fault. https://svn.boost.org/trac/boost/ticket/10272 I am working on a fix right now and should be done today-tomorrow. Alexander
On 7/29/2014 8:15 PM, Alexander Bogdashevsky wrote:
Not sure if this is a show-stopper or not, but property_tree API was broken a little. My fault.
https://svn.boost.org/trac/boost/ticket/10272
I am working on a fix right now and should be done today-tomorrow.
What is "broken a little"? Can you help us to assess the seriousness of the regression? Does it break common usage scenarios? Eric
On 7/29/2014 8:15 PM, Alexander Bogdashevsky wrote:
Not sure if this is a show-stopper or not, but property_tree API was broken a little. My fault.
https://svn.boost.org/trac/boost/ticket/10272
I am working on a fix right now and should be done today-tomorrow.
What is "broken a little"? Can you help us to assess the seriousness of the regression? Does it break common usage scenarios?
Yes, it does break common usage scenario. See ticket https://svn.boost.org/trac/boost/ticket/10272 for example. I just pushed a fix for this issue https://github.com/sanderbog/property_tree/commit/4e16d57fa634fc9ddb64cde1c6... Could somebody with good enough privileges merge it? Kind Regards, Alexander
On 7/30/2014 8:47 PM, Alexander Bogdashevsky wrote:
On 7/29/2014 8:15 PM, Alexander Bogdashevsky wrote:
Not sure if this is a show-stopper or not, but property_tree API was broken a little. My fault.
https://svn.boost.org/trac/boost/ticket/10272
I am working on a fix right now and should be done today-tomorrow.
What is "broken a little"? Can you help us to assess the seriousness of the regression? Does it break common usage scenarios?
Yes, it does break common usage scenario. See ticket https://svn.boost.org/trac/boost/ticket/10272 for example.
I just pushed a fix for this issue https://github.com/sanderbog/property_tree/commit/4e16d57fa634fc9ddb64cde1c6... Could somebody with good enough privileges merge it?
This fix hasn't even been merged to develop yet, and we're trying to get out a second RC. (The pull request(*) looks very dirty; can you clean it up so it only has the commit you want merged?) I think it's missed the boat. Besides, the test results look good on both develop and master, and the Property_tree maintainer hasn't had a chance to weigh in. This might be an intentional change -- I can't say at this point. Sebastian, can you have a look at the bug report and the patch and say what you think? (Even if it's a good fix, I think it has to wait at this point.) Eric (*) https://github.com/boostorg/property_tree/pull/5
participants (12)
-
Adam Wulkiewicz -
Alexander Bogdashevsky -
Andrey Semashev -
Barend Gehrels -
Belcourt, Kenneth -
Edward Diener -
Eric Niebler -
Ernest Galbrun -
Joaquin M Lopez Munoz -
Marshall Clow -
Niall Douglas -
Paul A. Bristow