On Tue, Jul 8, 2014 at 5:10 PM, Belcourt, Kenneth wrote:

On Jul 8, 2014, at 3:07 PM, Beman Dawes wrote:

...

Marshall is just a few days away from being able to put out a beta release candidate. (And that is very good news!)

But we still have too many libraries failing across the board on master:

accumulators interprocess numeric/ublas pool proto spirit/repository spirit/test tr1 wave

See http://www.boost.org/development/tests/master/developer/summary.html

What is the hold up with these? Does anyone need help?

I've been on travel and unable to merge a bunch of fixes from develop to master. Is it still okay to do that?

I'll say yes, assuming they are fixes and have been tested on develop, but only if done right away. Marshall may well want to stop all changes to master while he puts together the RC, but I'm hoping he will let us know beforehand. --Beman

On Tue, Jul 8, 2014 at 5:37 PM, Robert Ramey wrote:

Beman Dawes wrote

...

On Tue, Jul 8, 2014 at 5:10 PM, Belcourt, Kenneth <

...

kbelco@

...

> wrote:

Marshall may well want to stop all changes to master while he puts together the RC, but I'm hoping he will let us know beforehand.

Hmmm - Isn't that backwards? That is shouldn't we suspend generation releases until the master tests all pass?

Doesn't scale. Trying to get all master tests to pass is what delayed 1.36 and prior releases so long. Since then we have been on a quarterly schedule. That schedule was temporarily broken by the Git/Modularization conversion, but now we are planning restart quarterly releases. --Beman

...

But we still have too many libraries failing across the board on master:

tr1

Some days ago I opened a pull request for type_traits that fixes two of the tr1 tests: https://github.com/boostorg/type_traits/pu ll/2

Ah thanks! Is it OK to merge this to master? It effects only the tests not the headers. John.

Most of the other tr1 failures at least on MSVC 11 and 12 seem to be caused by TR1 living in the std namespace instead of std::tr1, not by actual errors in the boost library.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost .

Beman Dawes wrote

On Wed, Jul 9, 2014 at 2:24 AM, Eric Niebler <

eniebler@

> wrote: <sigh> Someday we will have an automatic testing system that rejects changes which break other libraries. </sigh>

If the development tests for library X where run against the current boost master, one would have notice of these problems while in development rather than at some later time. Note that even if the boost official development doesn't do this, a developer can easily set up his own environment this way to run his own tests. This is what I do on my own machine so generally I don't have this problem. see http://www.boost.org/development/tests/develop/developer/serialization.html . Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/Libraries-failing-across-the-board-tp4664... Sent from the Boost - Dev mailing list archive at Nabble.com.

On Wednesday 09 July 2014 13:01:23 John Maddock wrote:

...

...

Marshall is just a few days away from being able to put out a beta release candidate. (And that is very good news!)

But we still have too many libraries failing across the board on master:

accumulators interprocess numeric/ublas pool

Pool hasn't been maintained (or changed) in years.

The failures seem to be caused by something in /boost/core/demangle.hpp, so the pool lib seems to be an innocent bystander here?

The failing test #defines free to a non-existing symbol, and demangle.hpp uses free() and this causes the failure. If free is defined as a macro on some platform, it must be compatible with the function call syntax, so to my mind the test is broken.

I've submitted a pull request - someone from the community maintenance team will have to apply this and the other pending fix though. John.

On Wed, Jul 9, 2014 at 8:13 AM, John Maddock wrote:

On 08/07/2014 22:07, Beman Dawes wrote:

...

Marshall is just a few days away from being able to put out a beta release candidate. (And that is very good news!)

But we still have too many libraries failing across the board on master:

accumulators interprocess numeric/ublas pool proto spirit/repository spirit/test tr1

TR1 is now deprecated, and again hasn't been changed in a long time - the main failures seem to be caused by changes to Boost.Random (or possibly std::random) so that it is now no longer TR1 compliant. Someone would have to rewrite it to use TR1-compatible random number classes perhaps culled from an old version of Boost, frankly I just don't see the point. The lib should probably be removed from Boost at some point.

+1 How about for 1.56 (1) Removing TR1 from the regression tests, (2) Adding a release note deprecating it now with intent to remove from Boost in 1.57, (3) ditto in the TR1 docs. If you are OK with that, or something similar, we should also post the plan on the developers page so others will see it and can comment. --Beman

On Wed, Jul 9, 2014 at 2:08 PM, John Maddock wrote:

TR1 is now deprecated, and again hasn't been changed in a long time - the

...

...

main failures seem to be caused by changes to Boost.Random (or possibly std::random) so that it is now no longer TR1 compliant. Someone would have to rewrite it to use TR1-compatible random number classes perhaps culled from an old version of Boost, frankly I just don't see the point. The lib should probably be removed from Boost at some point.

+1

How about for 1.56 (1) Removing TR1 from the regression tests, (2) Adding a release note deprecating it now with intent to remove from Boost in 1.57, (3) ditto in the TR1 docs.

If you are OK with that, or something similar, we should also post the plan on the developers page so others will see it and can comment.

The docs currently have:

"Important

This library is deprecated in favor of native C++11 standard library features, as a result it receives little or no maintenance. "

Does it need to say more at this stage?

I don't think so. Any reason not to just remove the TR1 library? --Beman

On Wed, Jul 9, 2014 at 2:30 PM, John Maddock wrote:

I don't think so. Any reason not to just remove the TR1 library?

...

Well this will be the first release with it officially deprecated, so I'd say wait till the next release at least before pulling it ;)

Makes sense:-) I've put a note on the calendar to remove it Monday, August 27th. --Beman