[1.36.0] RELEASE BRANCH OPEN FOR BUG FIXES
Since there seems to be some confusion as to what can be currently done in the release cycle here's a reminder... ******************************************************************** The release branch is open for bug fixes and minor changes to all libraries through July 2nd. ******************************************************************** Merging in such bug fixes *does not* need any permission from the release manager! I.e. just do it! And in case you missed the previous communications: * Original 1.36.0 schedule announcement at: <http://lists.boost.org/Archives/boost/2008/05/137830.php> * Google Calendar with the release dates is at: <http://www.boost.org/community/index.html>. * Release schedule explanation at: <http://svn.boost.org/trac/boost/wiki/ReleaseSchedule>. * Release practices for everyone to follow at: <http://svn.boost.org/trac/boost/wiki/ImprovingPractices>. Bookmark, memorize, carve, or whatever else you need to do to remember this information ;-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
Since I've missed the time to merge Boost Exception in the release branch (for which I apologize), we now have two options with this regard: to wait until the next Boost release, or for me to get a permission to merge now. I don't have a strong preference either way. Please let me know what I should do. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode On Mon, Jun 23, 2008 at 8:06 AM, Rene Rivera <grafikrobot@gmail.com> wrote:
Since there seems to be some confusion as to what can be currently done in the release cycle here's a reminder...
******************************************************************** The release branch is open for bug fixes and minor changes to all libraries through July 2nd. ********************************************************************
Merging in such bug fixes *does not* need any permission from the release manager! I.e. just do it!
And in case you missed the previous communications:
* Original 1.36.0 schedule announcement at: <http://lists.boost.org/Archives/boost/2008/05/137830.php>
* Google Calendar with the release dates is at: <http://www.boost.org/community/index.html>.
* Release schedule explanation at: <http://svn.boost.org/trac/boost/wiki/ReleaseSchedule>.
* Release practices for everyone to follow at: <http://svn.boost.org/trac/boost/wiki/ImprovingPractices>.
Bookmark, memorize, carve, or whatever else you need to do to remember this information ;-)
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Ion has merged major evolutions from the trunc for interprocess and intrusive just yesterday. Hartmut has merged major evolutions from the trunc for wave and spirit just on 22/06. If the trunc regression is good I don't see any problem you add your library. A lot of other boost libraries will be based on your exception library. Best Vicente ----- Original Message ----- From: "Emil Dotchevski" <emil@revergestudios.com> To: <boost@lists.boost.org> Sent: Tuesday, June 24, 2008 1:20 AM Subject: Re: [boost] [1.36.0] RELEASE BRANCH OPEN FOR BUG FIXES
Since I've missed the time to merge Boost Exception in the release branch (for which I apologize), we now have two options with this regard: to wait until the next Boost release, or for me to get a permission to merge now.
I don't have a strong preference either way. Please let me know what I should do.
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Mon, Jun 23, 2008 at 8:06 AM, Rene Rivera <grafikrobot@gmail.com> wrote:
Since there seems to be some confusion as to what can be currently done in the release cycle here's a reminder...
******************************************************************** The release branch is open for bug fixes and minor changes to all libraries through July 2nd. ********************************************************************
Merging in such bug fixes *does not* need any permission from the release manager! I.e. just do it!
And in case you missed the previous communications:
* Original 1.36.0 schedule announcement at: <http://lists.boost.org/Archives/boost/2008/05/137830.php>
* Google Calendar with the release dates is at: <http://www.boost.org/community/index.html>.
* Release schedule explanation at: <http://svn.boost.org/trac/boost/wiki/ReleaseSchedule>.
* Release practices for everyone to follow at: <http://svn.boost.org/trac/boost/wiki/ImprovingPractices>.
Bookmark, memorize, carve, or whatever else you need to do to remember this information ;-)
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi Rene.
Since there seems to be some confusion as to what can be currently done in the release cycle here's a reminder...
******************************************************************** The release branch is open for bug fixes and minor changes to all libraries through July 2nd. ********************************************************************
Merging in such bug fixes *does not* need any permission from the release manager! I.e. just do it!
And in case you missed the previous communications:
* Original 1.36.0 schedule announcement at: <http://lists.boost.org/Archives/boost/2008/05/137830.php>
* Google Calendar with the release dates is at: <http://www.boost.org/community/index.html>.
* Release schedule explanation at: <http://svn.boost.org/trac/boost/wiki/ReleaseSchedule>.
* Release practices for everyone to follow at: <http://svn.boost.org/trac/boost/wiki/ImprovingPractices>.
Bookmark, memorize, carve, or whatever else you need to do to remember this information ;-)
Is there any chance of adding some sort of a 'release status' page on the web site under the 'development' menu item which would list all this information? Best regards, Jurko Gospodnetić
Rene Rivera skrev:
Since there seems to be some confusion as to what can be currently done in the release cycle here's a reminder...
******************************************************************** The release branch is open for bug fixes and minor changes to all libraries through July 2nd. ********************************************************************
Merging in such bug fixes *does not* need any permission from the release manager! I.e. just do it!
Hi Beman & Rene, Would it be ok to merge my updates for ptr_container into the release branch? These changes are more than just bug-fixes. When I compare http://www.boost.org/development/tests/release/developer/summary.html with http://www.boost.org/development/tests/trunk/developer/ptr_container.html then all the compilers in the release view pass all test (though not all compilers in the trunk view pass all tests). -Thorsten
Thorsten, Go ahead and merge to release, but do either fix or markup any failures with other compilers. --Beman On Tue, Jun 24, 2008 at 11:59 AM, Thorsten Ottosen < thorsten.ottosen@dezide.com> wrote:
Rene Rivera skrev:
Since there seems to be some confusion as to what can be currently done in the release cycle here's a reminder...
******************************************************************** The release branch is open for bug fixes and minor changes to all libraries through July 2nd. ********************************************************************
Merging in such bug fixes *does not* need any permission from the release manager! I.e. just do it!
Hi Beman & Rene,
Would it be ok to merge my updates for ptr_container into the release branch? These changes are more than just bug-fixes.
When I compare
http://www.boost.org/development/tests/release/developer/summary.html
with
http://www.boost.org/development/tests/trunk/developer/ptr_container.html
then all the compilers in the release view pass all test (though not all compilers in the trunk view pass all tests).
-Thorsten
What about Boost Exception? Should I merge it into release? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
What about Boost Exception? Should I merge it into release?
Let's see... 1 inspection problem: boost/exception/enable_current_exception.hpp: *T* So you need to convert tabs in that file to spaces. There are still a bunch of trunk regression test failures showing, although some are stale so may have been fixed by now. But you need to fix any remaining failures, or mark them up as expected. Once that that is taken care of, you can go ahead and merge. --Beman
I think Boost Exception is ready to be released but I wanted to confirm once again that I'm not missing something. Please bear with me I haven't released anything in Boost before. :) Looking here: http://www.boost.org/development/tests/trunk/developer/issues.html There is a single msvc 8.0 failure for Boost Exception which I'm certain is because it's an incremental test. The library does work on msvc 8. I need advice on what (if any) is the correct markup to use in explicit-failures-markup.xml for the failures reported here: http://www.boost.org/development/tests/trunk/developer/exception.html Some of the failures are intrusive_ptr-related (which Boost Exception uses) but they aren't marked as part of the known failures of the intrusive lib. There are also several signal 4/6 failures on HP-UX_pa_risc_aCC with no useful logs, and the Borland failures which I hope I am not required to fix. :) Thanks, Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode On Wed, Jun 25, 2008 at 10:44 AM, Beman Dawes <bdawes@acm.org> wrote:
Emil Dotchevski wrote:
What about Boost Exception? Should I merge it into release?
Let's see...
1 inspection problem: boost/exception/enable_current_exception.hpp: *T*
So you need to convert tabs in that file to spaces.
There are still a bunch of trunk regression test failures showing, although some are stale so may have been fixed by now. But you need to fix any remaining failures, or mark them up as expected.
Once that that is taken care of, you can go ahead and merge.
--Beman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Emil Dotchevski wrote:
I think Boost Exception is ready to be released but I wanted to confirm once again that I'm not missing something. Please bear with me I haven't released anything in Boost before. :)
Looking here:
http://www.boost.org/development/tests/trunk/developer/issues.html
There is a single msvc 8.0 failure for Boost Exception which I'm certain is because it's an incremental test. The library does work on msvc 8.
Why should an incremental test fail in this case? If you don't know, there's a mystery waiting to be uncovered and you shouldn't be so sure that it's a false positive in this case. If you do know, you should change your test so that it can work when run incrementally. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Why should an incremental test fail in this case? If you don't know, there's a mystery waiting to be uncovered and you shouldn't be so sure that it's a false positive in this case.
This is not a compiler or library bug; it is specific to http://www.boost.org/development/tests/trunk/RudbekAssociates-V2.html. Incremental MSVC builds at other sites work fine. I'm pretty sure that this particular problem has persisted for months now. I've tried to contact them before without success.
If you do know, you should change your test so that it can work when run incrementally.
Maybe I've set up the Boost Exception testing suite incorrectly? I doubt it, the relevant command is pretty straight-forward: run throw_exception_test.cpp helper2.cpp ; Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode On Thu, Jun 26, 2008 at 7:12 PM, David Abrahams <dave@boostpro.com> wrote:
Emil Dotchevski wrote:
I think Boost Exception is ready to be released but I wanted to confirm once again that I'm not missing something. Please bear with me I haven't released anything in Boost before. :)
Looking here:
http://www.boost.org/development/tests/trunk/developer/issues.html
There is a single msvc 8.0 failure for Boost Exception which I'm certain is because it's an incremental test. The library does work on msvc 8.
-- Dave Abrahams BoostPro Computing http://www.boostpro.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Emil Dotchevski escribió:
Why should an incremental test fail in this case? If you don't know, there's a mystery waiting to be uncovered and you shouldn't be so sure that it's a false positive in this case.
This is not a compiler or library bug; it is specific to http://www.boost.org/development/tests/trunk/RudbekAssociates-V2.html.
Incremental MSVC builds at other sites work fine. I'm pretty sure that this particular problem has persisted for months now. I've tried to contact them before without success.
This may or may not be related, but I (and other libs) have had problems with incremental linking in this regression runner, please see the complete discussion thread at: http://lists.boost.org/boost-testing/2007/07/4443.php However, the kind of problems talked about at the thread above are chaacterized by LNK1000 fatal errors, which is not what you're having, so I'm not sure we're dealing with the same issue. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
AMDG Emil Dotchevski wrote:
Why should an incremental test fail in this case? If you don't know, there's a mystery waiting to be uncovered and you shouldn't be so sure that it's a false positive in this case.
This is not a compiler or library bug; it is specific to http://www.boost.org/development/tests/trunk/RudbekAssociates-V2.html.
Incremental MSVC builds at other sites work fine. I'm pretty sure that this particular problem has persisted for months now. I've tried to contact them before without success.
Did you notice the line number? ..\libs\exception\test\throw_exception_test.cpp(55): test 'false' failed in function 'void __cdecl tester<struct boost::exception_test::some_boost_exception>(void)' Something is a little funny here because the test is on line 57. In Christ, Steven Watanabe
David Abrahams-3 wrote:
Emil Dotchevski wrote:
I think Boost Exception is ready to be released but I wanted to confirm once again that I'm not missing something. Please bear with me I haven't released anything in Boost before. :)
Looking here:
http://www.boost.org/development/tests/trunk/developer/issues.html
There is a single msvc 8.0 failure for Boost Exception which I'm certain is because it's an incremental test. The library does work on msvc 8.
Why should an incremental test fail in this case? If you don't know, there's a mystery waiting to be uncovered and you shouldn't be so sure that it's a false positive in this case. If you do know, you should change your test so that it can work when run incrementally.
The RudbekAssociates-V2 runner is showing 2 sets of results for the throw_exception_test test: --- boost/bin.v2/libs/exception/test/throw_exception_test.test/msvc-8.0/debug/link-static/runtime-link-static --- boost/bin.v2/libs/exception/test/throw_exception_test.test/msvc-8.0/debug/threading-multi --- Where the 'link-static' version is failing and the other isn't. The exception jamfile used to specify <link>static, but doesnt any more, so is the 'failure' just because theres a set of old results lying around as well as the current ones? -- View this message in context: http://www.nabble.com/-1.36.0--RELEASE-BRANCH-OPEN-FOR-BUG-FIXES-tp18078659p... Sent from the Boost - Dev mailing list archive at Nabble.com.
AMDG David Abrahams wrote:
There is a single msvc 8.0 failure for Boost Exception which I'm certain is because it's an incremental test. The library does work on msvc 8.
Why should an incremental test fail in this case? If you don't know, there's a mystery waiting to be uncovered and you shouldn't be so sure that it's a false positive in this case. If you do know, you should change your test so that it can work when run incrementally.
Here's what's going on. The test results say: Output by test variants: boost/bin.v2/libs/exception/test/throw_exception_test.test/msvc-9.0/debug/link-static/runtime-link-static <http://www.boost.org/development/tests/trunk/output/RudbekAssociates-V2-boost-bin-v2-libs-exception-test-throw_exception_test-test-msvc-9-0-debug-link-static-runtime-link-static.html> boost/bin.v2/libs/exception/test/throw_exception_test.test/msvc-9.0/debug/threading-multi At some point the properties used to build the test changed from link=static runtime-link=static to threading=multi. The old results are still present in the jam log and are getting picked up by the regression tools. The version that is currently being run is passing. In Christ, Steven Watanabe
Steven Watanabe wrote:
At some point the properties used to build the test changed from link=static runtime-link=static to threading=multi.
The old results are still present in the jam log and are getting picked up by the regression tools. The version that is currently being run is passing.
Good sleuthing, Steven! I presume someone knows how to blow away the old jam log? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
I completely failed to look at the dates in the log and see that they're from April! I thought that it's a different problem. Thanks guys! Alright then. Should I merge the Exception library in the release branch now? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode On Fri, Jun 27, 2008 at 10:15 AM, David Abrahams <dave@boostpro.com> wrote:
Steven Watanabe wrote:
At some point the properties used to build the test changed from link=static runtime-link=static to threading=multi.
The old results are still present in the jam log and are getting picked up by the regression tools. The version that is currently being run is passing.
Good sleuthing, Steven! I presume someone knows how to blow away the old jam log?
-- Dave Abrahams BoostPro Computing http://www.boostpro.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
AMDG David Abrahams wrote:
Steven Watanabe wrote:
At some point the properties used to build the test changed from link=static runtime-link=static to threading=multi.
The old results are still present in the jam log and are getting picked up by the regression tools. The version that is currently being run is passing.
Good sleuthing, Steven! I presume someone knows how to blow away the old jam log?
A full run would do it. I think that to avoid this problem in the future, the --dump-tests code in testing.jam needs to be reworked to print the actual targets rather than the main targets. In Christ, Steven Watanabe
David Abrahams wrote:
Steven Watanabe wrote:
At some point the properties used to build the test changed from link=static runtime-link=static to threading=multi.
The old results are still present in the jam log and are getting picked up by the regression tools. The version that is currently being run is passing.
Good sleuthing, Steven! I presume someone knows how to blow away the old jam log?
It isn't the jam log, but rather the old results xml file. This is similar to several other problems we have with the current regression framework in that it can currently only be solved on the tester's machine. Test frameworks that store results on a central server would be an improvement in that such problems can be fixed (or more likely won't even occur in the first place) without access to the tester's machine. Hopefully, the CMake based testing under development will avoid this trap. --Beman
Beman Dawes wrote:
Hopefully, the CMake based testing under development will avoid this trap.
By the way... The build system has no bearing on this problem. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
participants (10)
-
Beman Dawes -
David Abrahams -
Emil Dotchevski -
joaquin＠tid.es -
Jurko Gospodnetić -
Rene Rivera -
Richard Webb -
Steven Watanabe -
Thorsten Ottosen -
vicente.botet