On 1 December 2017 at 16:18, Robert Ramey via Boost wrote:

I would like to merge the develop branch into the merge branch for the serialization library. The most recent round of changes has been well tested and the test matrix is looking the best it has in years. I believe that doing this today, would carry small risk and that with 12 days to go, there would be time to address any unforseen (and hopefully unlikely) disaster.

Go ahead, although it is quite a large change for this stage. If there is a problem that isn't trivial to fix, I'd be inclined to revert it rather than try to fix it in this release.

On 1 December 2017 at 18:10, Barend Gehrels via Boost wrote:

Thanks for your question. As a team we would like to merge the last changes of Boost.Geometry to master. Boost.Geometry has been merged recently (on November 7, for Boost 1.66), but after that several fixes have been made. The regression matrix (last commits of code were Wednesday) is fine with it.

There are a lot of differences on master and develop which makes it tricky to tell what you want to merge. But assuming that you're only merging changes to source files that already on master and the relevant new tests, then go ahead.

On 1. Dec 2017, at 20:53, Daniel James via Boost wrote:

On 1 December 2017 at 19:46, Daniel Frey wrote:

...

There is one small bug-fix for Boost.Operators I'd like to merge. The commit is https://github.com/boostorg/utility/commit/ad0fc7c9d3d21d5ae3d594c41ed47ca71..., fixing boostorg/utility issue #35: https://github.com/boostorg/utility/issues/35

It's been in develop for a week now and the regression tests look good AFAICT.

OK to merge to master?

Yes, that looks good.

Thanks & done.

On 2 December 2017 at 03:18, Kohei Takahashi via Boost wrote:

I'd like to merge a PR into master for fusion library, which fixes a regression on buggy (msvc) compiler.

https://github.com/boostorg/fusion/pull/162

Boost.regression shows the test was passed on develop.

That looks okay. It looks like it changes behaviour for volatile types, but I assume that's intentional?

On 2 December 2017 at 14:26, Kohei Takahashi via Boost wrote:

Yes, the ctor should not be chosen for copying in the first place. The `disable_if` was added for fixing a bug in this beta, so I assume the change affects no existing user code.

OK, and sorry for not replying to your previous email about this.