On Tue, Jul 2, 2013 at 11:54 AM, Oliver Kowalke wrote:

2013/7/2 Ben Pope

...

On 02/07/13 15:31, Oliver Kowalke wrote:

...

unfortunately boost-1.54 needs a bugfix - because my request to merge boost.coroutine into release a required bugfix was not applied :(

I'm wondering because the regression-tests are passed?!

what to do? should I modify the fix in boost-release and archives of boost-1.54 are rebuild?

It might be useful to supply the diff and changelist here.

Why? building boost from boost-root fails with: 'error: No best alternative for libs/coroutine/build/allocator_sources'

I believe, if you have a fix, displaying it here would allow the release management team to evaluate the impact of applying it at such a late stage. Also, if you have a non-intrusive hotfix (like, some particular b2 options to make it build), this might be a viable solution for 1.54 as well. I think, the configuration conflict can be worked around if you specify some of the conflicting properties manually. This may well be the reason why this hasn't come up in test results.

2013/7/2 John Maddock

unfortunately boost-1.54 needs a bugfix - because my request to merge

...

boost.coroutine into release a required bugfix was not applied :(

I'm wondering because the regression-tests are passed?!

what to do? should I modify the fix in boost-release and archives of boost-1.54 are rebuild?

Unless it's a showstopper, I'd say let 1.54 ship as is.

boost.coroutine does not build and therefore boost.asio would also not build (because of new async_result feature using coroutines).

And this is from someone who also failed to get a last minute patch applied (blame my gall bladder for knocking me over at the wrong moment!).

the bugfix was out-of-my focus because I did a lot work on boost.coroutine. because of many changes I forgot to fix the typo. As I sad the regression-tests on http://www.boost.org/development/tests/release/developer/coroutine.html are passed. Even if I do build boost.coroutine in libs/coroutine/examples or libs/coroutine/test the library builds. It fails only if b2 is called from boost-root - I assume this is an issue of boost-build system. To fix the bug in lib/coroutine/build/Jamfile.v2: - explicit yield_sources ; +explicit allocator_sources ;

On 2 July 2013 09:19, John Maddock wrote:

Unless it's a showstopper, I'd say let 1.54 ship as is. And this is from someone who also failed to get a last minute patch applied (blame my gall bladder for knocking me over at the wrong moment!).

Oh, nasty. I hope all's well now.

Assuming the move to git is to take place before the next release, and assuming that's going to be a longer than normal schedule

I don't know what's happening with git, but we have a 4 months scheduled for this release regardless.

I'd suggest that we either:

* Slip out 1.55 on a shorter than usual cycle (no new libraries?) to be completed before the move to git begins, or... * Put out a 1.54.1 with bug fixes only on a short 2-3 week cycle, again before the move to git.

We can at least put patches up on the site. Recently I've been adding links to the release notes page, although I want to do something better. A couple of times we tried creating maintenance branches for releases, but they never saw much use. But at least they're a decent way to gather patches together. They were at: https://svn.boost.org/svn/boost/branches/maintenance/ With git it should be easier for people to add patches to a stable release branch, although I'm not sure how we'll use them.

On 2 July 2013 19:08, Steve M. Robbins wrote:

On Tue, Jul 02, 2013 at 01:17:43PM +0100, Daniel James wrote:

...

We can at least put patches up on the site. Recently I've been adding links to the release notes page, although I want to do something better.

Hey, that's great! I really appreciate the effort to collect together any stabilizing fixes after the release is made. Whether it's in the form of a point release, or links on the release notes page, it makes my job of integrating Boost into the Debian Linux distribution easier.

Well, it'll only happen if people give me the patches. Currently there are only two linked patches, I imagine there probably should be a lot more.

On 3 July 2013 20:38, Marshall Clow wrote:

On Jul 2, 2013, at 2:59 PM, Daniel James wrote:

...

On 2 July 2013 19:08, Steve M. Robbins wrote:

...

On Tue, Jul 02, 2013 at 01:17:43PM +0100, Daniel James wrote:

...

We can at least put patches up on the site. Recently I've been adding links to the release notes page, although I want to do something better.

Hey, that's great! I really appreciate the effort to collect together any stabilizing fixes after the release is made. Whether it's in the form of a point release, or links on the release notes page, it makes my job of integrating Boost into the Debian Linux distribution easier.

Well, it'll only happen if people give me the patches. Currently there are only two linked patches, I imagine there probably should be a lot more.

This would be a good one, too: https://svn.boost.org/trac/boost/changeset/84626 [ I didn't merge it to the release branch in time; it causes a compilation failure when compiling for C++11 ]

I created a maintenance branch at: https://svn.boost.org/svn/boost/branches/maintenance/1_54_0 And have merged in that change, and the coroutine change. I'll put them somewhere on the website soon-ish.

On 6 July 2013 21:28, Steve M. Robbins wrote:

On July 3, 2013 05:14:07 PM Daniel James wrote:

...

I created a maintenance branch at:

https://svn.boost.org/svn/boost/branches/maintenance/1_54_0

And have merged in that change, and the coroutine change. I'll put them somewhere on the website soon-ish.

Thanks, that's helpful. I'd like to diff that against the boost release tarball to generate a patch for Debian.

However I notice dozens of timestamp changes such as the following that obscure the substantive changes. Any idea why these exist?

Because subversion is odd? It might be something to do with the way I merged it, but I'm not sure. Maybe a subversion branch isn't the best option. If we ever modularize, I assume you'll initially want patches against the monolithic release, rather than modules. So it'll either have to be a separate repo, or we'll have to work out some way to generate useful patches. Also, the subversion branch won't really work for documentation fixes. We've got them in a very awkward form at: http://svn.boost.org/svn/boost/website/public_html/live/doc/fixes/ http://svn.boost.org/svn/boost/website/public_html/live/doc/libs/ Anyway, I've put clean patches on the website, there's a page at: http://www.boost.org/patches/ It's very basic at the moment.

On 7 July 2013 06:47, Daniela Engert wrote:

Am 07.07.2013 00:29, schrieb Daniel James:

...

Because subversion is odd?

In this case, SVN works exactly as it is told to by someone who attached and set the svn:keywords property on a subset of boost's files: modify the related texts accordingly ('$Date:$' in this case).

You'd expect it to only do that for files that were actually modified though.

A set of diff files - one for each changeset - might get around this annoyance.

http://www.boost.org/patches/ Also underneath the downloads at: http://www.boost.org/users/history/version_1_54_0.html

Oliver Kowalke writes:

It would be nice if the distro maintainers would give feedback if they encountered some bugs in boost. I noticed that some (not necessary you) of those people write some bugfixes but do not inform the author of the boost-lib - that's a shame.

I plan to rebase to 1.54.0 (plus the maintenance patches) in Fedora 20. That involves rebuilds of client packages (200+ of them), which tends to uncover an odd bug here or there. I generally file tickets for bugs that I encounter. Thanks, PM

On 7 July 2013 08:59, Bronek Kozicki wrote:

On 02/07/2013 09:19, John Maddock wrote:

...

Where are we with the move to git?

Assuming the move to git is to take place before the next release, and assuming that's going to be a longer than normal schedule I'd suggest that we either:

* Slip out 1.55 on a shorter than usual cycle (no new libraries?) to be completed before the move to git begins, or... * Put out a 1.54.1 with bug fixes only on a short 2-3 week cycle, again before the move to git.

Since Daniel already created svn branch for 1.54 maintenance release may I suggest 1.54.1 is released in (small) few weeks time, with all the fixes brought up? It would help deployments in commercial environments where "1.54.1" is actual version of library one may download from boost, rather than 1.54.0 + (more or less) random collection of patches.

The branch isn't for a release, just to gather patches. The problem is that the it isn't fully tested, so it won't be blessed as official. I should probably make that clearer on the site. Btw. I'm not commenting on whether there should or shouldn't be a 1.54.1.

On 7 July 2013 09:12, Andrey Semashev wrote:

While we're at it, what is the status of the mentioned branch? E.g. if it is targeted for post-release fixes, am I allowed to backport fixes in my library to it? After tests passed on trunk, of course.

Yes, just remember that it's only for fixes. I don't want to micro-manage it, so just be responsible about it. I might combine a library's changes into a single patch if there are a lot of changes.

Le 07/07/13 10:24, Daniel James a écrit :

...

While we're at it, what is the status of the mentioned branch? E.g. if it is targeted for post-release fixes, am I allowed to backport fixes in my library to it? After tests passed on trunk, of course. Yes, just remember that it's only for fixes. I don't want to micro-manage it, so just be responsible about it. I might combine a

On 7 July 2013 09:12, Andrey Semashev wrote: library's changes into a single patch if there are a lot of changes.

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

Hi, there is a regression on Boost.Thread on Windows NT. See https://svn.boost.org/trac/boost/ticket/8070. The following patch https://svn.boost.org/trac/boost/changeset/84946 rollbacks the cause. Please, could you added it to the maintenance 1.54 branche? Best, Vicente