Are there any 1.48.0 showstoppers outstanding? We are scheduled to release right now. There are still a lot of release branch regression test failures. It is very uncomfortable to see failures for popular compilers such as VC++ 10 and GCC: accumulators (most or all compilers) assign flyweight (most or all compilers) graph ublas pool (all Windows compilers) ptr_container (most or all compilers) python spirit/repository (most or all compilers) tr1 (most or all compilers) wave (all Windows compilers) See http://beta.boost.org/development/tests/release/developer/summary.html Do we really want to release with this many failures? Worried, --Beman
On Tue, Nov 8, 2011 at 3:06 PM, Beman Dawes <bdawes@acm.org> wrote:
Are there any 1.48.0 showstoppers outstanding? We are scheduled to release right now.
Yes (IMO): https://svn.boost.org/trac/boost/ticket/6104 Olaf
On Tue, Nov 8, 2011 at 9:42 AM, Olaf van der Spek <ml@vdspek.org> wrote:
On Tue, Nov 8, 2011 at 3:06 PM, Beman Dawes <bdawes@acm.org> wrote:
Are there any 1.48.0 showstoppers outstanding? We are scheduled to release right now.
Yes (IMO): https://svn.boost.org/trac/boost/ticket/6104
Is there something about that lexical_cast problem that makes it worthwhile to hold the 1.48.0 release? There are several hundred bugs I wish we had fixes for, but we will never get a release out if we wait 'til they are all fixed. --Beman
On Tue, Nov 8, 2011 at 4:39 PM, Beman Dawes <bdawes@acm.org> wrote:
Is there something about that lexical_cast problem that makes it worthwhile to hold the 1.48.0 release?
Depends on the goals / requirements Boost has for releases.
There are several hundred bugs I wish we had fixes for, but we will never get a release out if we wait 'til they are all fixed.
If you're fine with apps that used to work fine 1.47 segfaulting with 1.48 then there's no reason to hold 1.48. -- Olaf
On Tue, Nov 8, 2011 at 9:55 AM, Marshall Clow <mclow.lists@gmail.com> wrote:
On Nov 8, 2011, at 6:06 AM, Beman Dawes wrote:
Are there any 1.48.0 showstoppers outstanding? We are scheduled to release right now.
Well, there are 72 open tickets in Trac marked as "showstopper". :-
From the standpoint of shipping a release, at the end of a release cycle, about the only thing I consider a showstopper is something that makes most of Boost unusable, particularly for a popular platform. I also get concerned when a library, particularly a popular one, has a lot of failures.
IFAIK, none of those tickets come anywhere close to that level of concern. I'm guessing most were classified as "showstopper" because they were important to the submitter. --Beman
On Nov 8, 2011, at 7:35 AM, Beman Dawes wrote:
On Tue, Nov 8, 2011 at 9:55 AM, Marshall Clow <mclow.lists@gmail.com> wrote:
On Nov 8, 2011, at 6:06 AM, Beman Dawes wrote:
Are there any 1.48.0 showstoppers outstanding? We are scheduled to release right now.
Well, there are 72 open tickets in Trac marked as "showstopper". :-
From the standpoint of shipping a release, at the end of a release cycle, about the only thing I consider a showstopper is something that makes most of Boost unusable, particularly for a popular platform. I also get concerned when a library, particularly a popular one, has a lot of failures.
IFAIK, none of those tickets come anywhere close to that level of concern. I'm guessing most were classified as "showstopper" because they were important to the submitter.
You'll get no argument from me on that score. However, I think we ought to go through those bugs and decide which, if any, actually are "showstoppers" [ Before the next (1.49) release, I mean ] In https://svn.boost.org/trac/boost/wiki/TicketWorkflow, we have (in fact, I think I wrote): Severity - how bad is this ticket? Showstopper - this problem is so bad, that we should hold up a release if it's not fixed. Note that the release managers and/or the library maintainers may have different opinions. Regression - something used to work (in a previous release), but no longer does. Problem - the default value. Optimization - this makes the library work better (usually with a patch enclosed). Cosmetic - minor problems, like using the wrong "they're/there/their" in a comment, or a typo in the documentation. Do not be discouraged from creating tickets for "minor" issues like this. They're easy to fix, and they make boost better. Then again, I think that the status of the bug list, and getting things fixed, needs some serious work anyway. (given that we currently have almost 1250 open tickets) -- Marshall
On 11/8/2011 6:06 AM, Beman Dawes wrote:
There are still a lot of release branch regression test failures. It is very uncomfortable to see failures for popular compilers such as VC++ 10 and GCC:
accumulators (most or all compilers)
These tests broke several releases ago due to a change in Boost.Random, which is only used in the Accumulator's regression tests. Steven assures me it's not due to a bug in Random, but I still have my doubts. Regardless, I haven't had the time to investigate, so the tests have stayed broken. There is nothing wrong with Boost.Accumulators, though. -- Eric Niebler BoostPro Computing http://www.boostpro.com
AMDG On 11/08/2011 07:40 AM, Eric Niebler wrote:
On 11/8/2011 6:06 AM, Beman Dawes wrote:
There are still a lot of release branch regression test failures. It is very uncomfortable to see failures for popular compilers such as VC++ 10 and GCC:
accumulators (most or all compilers)
These tests broke several releases ago due to a change in Boost.Random, which is only used in the Accumulator's regression tests. Steven assures me it's not due to a bug in Random, but I still have my doubts. Regardless, I haven't had the time to investigate, so the tests have stayed broken. There is nothing wrong with Boost.Accumulators, though.
I fixed all these tests in the trunk a few weeks ago. In Christ, Steven Watanabe
On 11/8/2011 7:53 AM, Steven Watanabe wrote:
On 11/08/2011 07:40 AM, Eric Niebler wrote:
On 11/8/2011 6:06 AM, Beman Dawes wrote:
accumulators (most or all compilers)
These tests broke several releases ago due to a change in Boost.Random, <snip>
I fixed all these tests in the trunk a few weeks ago.
So you did! Thanks! -- Eric Niebler BoostPro Computing http://www.boostpro.com
On Wed, Nov 9, 2011 at 1:19 AM, Eric Niebler <eric@boostpro.com> wrote:
On 11/8/2011 7:53 AM, Steven Watanabe wrote:
On 11/08/2011 07:40 AM, Eric Niebler wrote:
On 11/8/2011 6:06 AM, Beman Dawes wrote:
accumulators (most or all compilers)
These tests broke several releases ago due to a change in Boost.Random, <snip>
I fixed all these tests in the trunk a few weeks ago.
So you did! Thanks!
Should the fixes be merged to release? --Beman
On 11/9/2011 9:06 AM, Beman Dawes wrote:
On Wed, Nov 9, 2011 at 1:19 AM, Eric Niebler <eric@boostpro.com> wrote:
On 11/8/2011 7:53 AM, Steven Watanabe wrote:
On 11/08/2011 07:40 AM, Eric Niebler wrote:
On 11/8/2011 6:06 AM, Beman Dawes wrote:
accumulators (most or all compilers)
These tests broke several releases ago due to a change in Boost.Random, <snip>
I fixed all these tests in the trunk a few weeks ago.
So you did! Thanks!
Should the fixes be merged to release?
Done. -- Eric Niebler BoostPro Computing http://www.boostpro.com
AMDG On 11/08/2011 08:54 AM, John Maddock wrote:
tr1 (most or all compilers)
Well I confess I've paid no attention to TR1 because there have been no changes.... however, it appears that the TR1 random number tests are failing on all compilers, for which I suspect a breaking change to Boost.Random. Steven?
It's the seeding algorithm. Seeding was a mess before, but apparently in cleaning it up I decided differently from TR1. (I was just going by the standard, which doesn't have floating point generators) In Christ, Steven Watanabe
on Tue Nov 08 2011, Steven Watanabe <watanabesj-AT-gmail.com> wrote:
AMDG
On 11/08/2011 08:54 AM, John Maddock wrote:
tr1 (most or all compilers)
Well I confess I've paid no attention to TR1 because there have been no changes.... however, it appears that the TR1 random number tests are failing on all compilers, for which I suspect a breaking change to Boost.Random. Steven?
It's the seeding algorithm. Seeding was a mess before, but apparently in cleaning it up I decided differently from TR1. (I was just going by the standard, which doesn't have floating point generators)
So what's the right way to resolve this? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
on Tue Nov 08 2011, Beman Dawes <bdawes-AT-acm.org> wrote:
Are there any 1.48.0 showstoppers outstanding? We are scheduled to release right now.
There are still a lot of release branch regression test failures. It is very uncomfortable to see failures for popular compilers such as VC++ 10 and GCC:
accumulators (most or all compilers) assign flyweight (most or all compilers) graph ublas pool (all Windows compilers) ptr_container (most or all compilers) python spirit/repository (most or all compilers) tr1 (most or all compilers) wave (all Windows compilers)
See http://beta.boost.org/development/tests/release/developer/summary.html
Do we really want to release with this many failures?
No. Aren't these regressions? Don't we have a policy against releasing with regressions? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Beman Dawes <bdawes <at> acm.org> writes:
pool (all Windows compilers)
The Windows Pool failures are in the "valgrind_config_check" test, which appears to just test if Valgrind is installed. I guess that this can be marked as an expected failure, given that Valgrind doesn't work on Windows?
pool (all Windows compilers)
The Windows Pool failures are in the "valgrind_config_check" test, which appears to just test if Valgrind is installed.
I guess that this can be marked as an expected failure, given that Valgrind doesn't work on Windows?
If we're taking about valgrind_config_check, then that shouldn't even be in the test matrix - indeed it's not for most of the testers - I'm not sure why it's showing up on just some. John.
There are still a lot of release branch regression test failures. It is very uncomfortable to see failures for popular compilers such as VC++ 10 and GCC:
accumulators (most or all compilers) assign flyweight (most or all compilers) graph ublas pool (all Windows compilers) ptr_container (most or all compilers) python spirit/repository (most or all compilers)
That's no showstopper to hold up the release. I'll have a look.
tr1 (most or all compilers) wave (all Windows compilers)
These are not real problems with the library but failures to match filenames with different delimiter conventions in the test itself (i.e. '/' vs. '\\'). No reason to hold up the release. I'll try to fix that anyways. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu
Beman Dawes <bdawes <at> acm.org> writes:
graph
for what it's worth, the VC9/10 Graph failures are down to these: https://svn.boost.org/trac/boost/ticket/6111 https://svn.boost.org/trac/boost/ticket/6112 Though the first one is actually an unordered issue that isn't picked up by it's own tests.
On Thu, 10 Nov 2011, Richard Webb wrote:
Beman Dawes <bdawes <at> acm.org> writes:
graph
for what it's worth, the VC9/10 Graph failures are down to these:
https://svn.boost.org/trac/boost/ticket/6111 https://svn.boost.org/trac/boost/ticket/6112
Though the first one is actually an unordered issue that isn't picked up by it's own tests.
I went through all of the source, test, and example files, so there shouldn't be any of these problems left in Boost.Graph itself. -- Jeremiah Willcock
On 10 November 2011 15:06, Jeremiah Willcock <jewillco@osl.iu.edu> wrote:
On Thu, 10 Nov 2011, Richard Webb wrote:
for what it's worth, the VC9/10 Graph failures are down to these:
https://svn.boost.org/trac/boost/ticket/6111 https://svn.boost.org/trac/boost/ticket/6112
Though the first one is actually an unordered issue that isn't picked up by it's own tests.
I fixed the unordered issue on trunk yesterday: https://svn.boost.org/trac/boost/changeset/75432/ The Visual C++ 9 tests have run and they're all passing for both unordered and graph, but the tests have only run for a few other platforms since the change. How much time is available for merging?
On Fri, Nov 11, 2011 at 8:52 AM, Daniel James <dnljms@gmail.com> wrote:
On 10 November 2011 15:06, Jeremiah Willcock <jewillco@osl.iu.edu> wrote:
On Thu, 10 Nov 2011, Richard Webb wrote:
for what it's worth, the VC9/10 Graph failures are down to these:
https://svn.boost.org/trac/boost/ticket/6111 https://svn.boost.org/trac/boost/ticket/6112
Though the first one is actually an unordered issue that isn't picked up by it's own tests.
I fixed the unordered issue on trunk yesterday:
https://svn.boost.org/trac/boost/changeset/75432/
The Visual C++ 9 tests have run and they're all passing for both unordered and graph, but the tests have only run for a few other platforms since the change. How much time is available for merging?
It would be great if you could merge by late Saturday, so release tests can cycle at least on a few platforms by Monday morning. I'd like to build the release candidate Monday. --Beman
There are some errors in math library: /home/cc/downloads/boost_1_48_0_beta1/include/boost/math/tools/config.hpp:283:7: error: ‘fexcept_t’ does not name a type /home/cc/downloads/boost_1_48_0_beta1/include/boost/math/tools/config.hpp: In constructor ‘boost::math::detail::fpu_guard::fpu_guard()’: /home/cc/downloads/boost_1_48_0_beta1/include/boost/math/tools/config.hpp:275:27: error: ‘m_flags’ was not declared in this scope /home/cc/downloads/boost_1_48_0_beta1/include/boost/math/tools/config.hpp:275:36: error: ‘FE_ALL_EXCEPT’ was not declared in this scope /home/cc/downloads/boost_1_48_0_beta1/include/boost/math/tools/config.hpp:275:49: error: ‘fegetexceptflag’ was not declared in this scope /home/cc/downloads/boost_1_48_0_beta1/include/boost/math/tools/config.hpp:276:37: error: ‘feclearexcept’ was not declared in this scope /home/cc/downloads/boost_1_48_0_beta1/include/boost/math/tools/config.hpp: In destructor ‘boost::math::detail::fpu_guard::~fpu_guard()’: /home/cc/downloads/boost_1_48_0_beta1/include/boost/math/tools/config.hpp:280:27: error: ‘m_flags’ was not declared in this scope /home/cc/downloads/boost_1_48_0_beta1/include/boost/math/tools/config.hpp:280:36: error: ‘FE_ALL_EXCEPT’ was not declared in this scope /home/cc/downloads/boost_1_48_0_beta1/include/boost/math/tools/config.hpp:280:49: error: ‘fesetexceptflag’ was not declared in this scope This can be fixed by commenting out lines from 268 to 288. Looks like preprocessor #if condition on line 264 is incorrect. Created ticket #6120 for this bug. Also, there is a regression from previous versions of boost in range library: /home/cc/downloads/boost_1_48_0_beta1/include/boost/range/iterator_range_core.hpp: In static member function ‘static IteratorT boost::iterator_range_detail::iterator_range_impl<IteratorT>::adl_begin(ForwardRange&) [with ForwardRange = const boost::iterator_range<const unsigned char*>, IteratorT = unsigned char*]’: /home/cc/downloads/boost_1_48_0_beta1/include/boost/range/iterator_range_core.hpp:186:76: instantiated from ‘boost::iterator_range<IteratorT>::iterator_range(const Range&) [with Range = boost::iterator_range<const unsigned char*>, IteratorT = unsigned char*]’ ../../../../margot/applications/index24/xsd_lazy_types_string_t.hpp:49:17: instantiated from here /home/cc/downloads/boost_1_48_0_beta1/include/boost/range/iterator_range_core.hpp:56:66: error: invalid static_cast from type ‘boost::range_iterator<const boost::iterator_range<const unsigned char*> >::type {aka const unsigned char*}’ to type ‘unsigned char*’ /home/cc/downloads/boost_1_48_0_beta1/include/boost/range/iterator_range_core.hpp: In static member function ‘static IteratorT boost::iterator_range_detail::iterator_range_impl<IteratorT>::adl_end(ForwardRange&) [with ForwardRange = const boost::iterator_range<const unsigned char*>, IteratorT = unsigned char*]’: /home/cc/downloads/boost_1_48_0_beta1/include/boost/range/iterator_range_core.hpp:186:76: instantiated from ‘boost::iterator_range<IteratorT>::iterator_range(const Range&) [with Range = boost::iterator_range<const unsigned char*>, IteratorT = unsigned char*]’ ../../../../margot/applications/index24/xsd_lazy_types_string_t.hpp:49:17: instantiated from here /home/cc/downloads/boost_1_48_0_beta1/include/boost/range/iterator_range_core.hpp:62:64: error: invalid static_cast from type ‘boost::range_iterator<const boost::iterator_range<const unsigned char*> >::type {aka const unsigned char*}’ to type ‘unsigned char*’ make: *** [../../../../margot/database/berkeleydb/bdb_database_indices.o] Error 1 Looks like there must be a const_cast instead of static_cast. Created ticket #6121 for this bug. Last error looks like a show-stopper for me. Best regards, Antony Polukhin
On Sun, Nov 13, 2011 at 4:42 AM, Antony Polukhin <antoshkka@gmail.com> wrote:
There are some errors in math library:
...> Created ticket #6120 for this bug.
Also, there is a regression from previous versions of boost in range library:
...> Looks like there must be a const_cast instead of static_cast.
Created ticket #6121 for this bug.
Last error looks like a show-stopper for me.
I've pinged John Maddock and Neil Groves privately asking them to look at these right away, since we were planning to ship 1.48.0 tomorrow. --Beman
There are some errors in math library:
This can be fixed by commenting out lines from 268 to 288. Looks like preprocessor #if condition on line 264 is incorrect. Created ticket #6120 for this bug.
What platform and compiler? Nothing in there has changed in a while BTW. Whatever the platform, it looks like it has an fenv.h but no fexcept_t, so maybe Boost.Config should be setting BOOST_NO_FENV_H? Fumbling in the dark yours, John.
2011/11/13 John Maddock <boost.regex@virgin.net>:
What platform and compiler? Nothing in there has changed in a while BTW.
It's a Linux, gcc-4.6.2. Intel Xeon processor. If you need more info, I can send it tomorrow. And yes, It`s an old (and very annoying) issue, that also can be reproduced with gcc-4.5 and some older versions of boost. It's a pity that I was told about it just a few days before release. If it has no fast and reliable solution, I think it can wait till next release. Best regards, Antony Polukhin
What platform and compiler? Nothing in there has changed in a while BTW.
It's a Linux, gcc-4.6.2. Intel Xeon processor. If you need more info,
I've put a tentative fix in Trunk, can you let me know if this fixes the issue as I can't reproduce it here? And yes, I think this is too late for 1.48. Regards, John.
On Mon, Nov 14, 2011 at 7:22 AM, John Maddock <boost.regex@virgin.net> wrote:
What platform and compiler? Nothing in there has changed in a while BTW.
It's a Linux, gcc-4.6.2. Intel Xeon processor. If you need more info,
I've put a tentative fix in Trunk, can you let me know if this fixes the issue as I can't reproduce it here?
And yes, I think this is too late for 1.48.
Agreed. Starting to build the release candidates now. --Beman
2011/11/14 John Maddock <boost.regex@virgin.net>:
I've put a tentative fix in Trunk, can you let me know if this fixes the issue as I can't reproduce it here?
Looks like it fixed the issue. Great thanks! 2011/11/13 Beman Dawes <bdawes@acm.org>:
On Sun, Nov 13, 2011 at 4:42 AM, Antony Polukhin <antoshkka@gmail.com> wrote:
There are some errors in math library:
...> Created ticket #6120 for this bug.
Also, there is a regression from previous versions of boost in range library:
...> Looks like there must be a const_cast instead of static_cast.
Created ticket #6121 for this bug.
Last error looks like a show-stopper for me.
I've pinged John Maddock and Neil Groves privately asking them to look at these right away, since we were planning to ship 1.48.0 tomorrow.
I`ve closed issue #6121 . It was an error in my code, not in iterator_range! Best regards, Antony Polukhin
On Sun, Nov 13, 2011 at 4:42 AM, Antony Polukhin <antoshkka@gmail.com> wrote: ...> Also, there is a regression from previous versions of boost in range library:
/home/cc/downloads/boost_1_48_0_beta1/include/boost/range/iterator_range_core.hpp: In static member function ‘static IteratorT boost::iterator_range_detail::iterator_range_impl<IteratorT>::adl_begin(ForwardRange&) [with ForwardRange = const boost::iterator_range<const unsigned char*>, IteratorT = unsigned char*]’: /home/cc/downloads/boost_1_48_0_beta1/include/boost/range/iterator_range_core.hpp:186:76: instantiated from ‘boost::iterator_range<IteratorT>::iterator_range(const Range&) [with Range = boost::iterator_range<const unsigned char*>, IteratorT = unsigned char*]’ ../../../../margot/applications/index24/xsd_lazy_types_string_t.hpp:49:17: instantiated from here /home/cc/downloads/boost_1_48_0_beta1/include/boost/range/iterator_range_core.hpp:56:66: error: invalid static_cast from type ‘boost::range_iterator<const boost::iterator_range<const unsigned char*> >::type {aka const unsigned char*}’ to type ‘unsigned char*’ /home/cc/downloads/boost_1_48_0_beta1/include/boost/range/iterator_range_core.hpp: In static member function ‘static IteratorT boost::iterator_range_detail::iterator_range_impl<IteratorT>::adl_end(ForwardRange&) [with ForwardRange = const boost::iterator_range<const unsigned char*>, IteratorT = unsigned char*]’: /home/cc/downloads/boost_1_48_0_beta1/include/boost/range/iterator_range_core.hpp:186:76: instantiated from ‘boost::iterator_range<IteratorT>::iterator_range(const Range&) [with Range = boost::iterator_range<const unsigned char*>, IteratorT = unsigned char*]’ ../../../../margot/applications/index24/xsd_lazy_types_string_t.hpp:49:17: instantiated from here /home/cc/downloads/boost_1_48_0_beta1/include/boost/range/iterator_range_core.hpp:62:64: error: invalid static_cast from type ‘boost::range_iterator<const boost::iterator_range<const unsigned char*> >::type {aka const unsigned char*}’ to type ‘unsigned char*’ make: *** [../../../../margot/database/berkeleydb/bdb_database_indices.o] Error 1
Looks like there must be a const_cast instead of static_cast. Created ticket #6121 for this bug.
Last error looks like a show-stopper for me.
I've pinged the maintainer but gotten no response. In the current regression test report for range, almost all compilers are passing all tests. A small number of compilers are failing one test, but passing all others. So we are not going to hold the release for this. --Beman
On Fri, 11 Nov 2011, Beman Dawes wrote:
On Fri, Nov 11, 2011 at 8:52 AM, Daniel James <dnljms@gmail.com> wrote:
On 10 November 2011 15:06, Jeremiah Willcock <jewillco@osl.iu.edu> wrote:
On Thu, 10 Nov 2011, Richard Webb wrote:
for what it's worth, the VC9/10 Graph failures are down to these:
https://svn.boost.org/trac/boost/ticket/6111 https://svn.boost.org/trac/boost/ticket/6112
Though the first one is actually an unordered issue that isn't picked up by it's own tests.
I fixed the unordered issue on trunk yesterday:
https://svn.boost.org/trac/boost/changeset/75432/
The Visual C++ 9 tests have run and they're all passing for both unordered and graph, but the tests have only run for a few other platforms since the change. How much time is available for merging?
It would be great if you could merge by late Saturday, so release tests can cycle at least on a few platforms by Monday morning. I'd like to build the release candidate Monday.
I did the 6112 merges to the release branch yesterday (for Boost.Graph), so those should be tested soon. -- Jeremiah Willcock
participants (12)
-
Antony Polukhin -
Beman Dawes -
Daniel James -
Dave Abrahams -
Eric Niebler -
Hartmut Kaiser -
Jeremiah Willcock -
John Maddock -
Marshall Clow -
Olaf van der Spek -
Richard Webb -
Steven Watanabe