Aleksey Gurtovoy wrote:

JOAQUIN LOPEZ MU?Z writes:

...

I don't want to sound harsh or anything, and I truly appreciate the effort that's being put in this, but a month has slipped by since the first schedule for releasing, and AFAIK we don't even have an agreed upon branching date for the near future.

The branching date is pending MPL check-in. The latter has been postponed several times as the new issues surfaced (in particular, due to better tests), but it's crucial to ensure that the library is in the predictable state before the release (remember that it goes on the CD with the TMP book), so please bear with us.

The branch should occur now. MPL update can go into the next release. Or you can see it a slightly different way. Branch and release 1.32 now. Rebranch and release 1.32 when MPL update has been added and any related issues resolved.

There are external constraints for this release's timeframe, but within those, the release is criteria-driven. One of the criteria is regression-free codebase,

This is criteria for release - not for branching

and another is the new MPL version. There is no point of releasing "on time" if the release is useless.

Nothing in the current development tree - i.e. the 1.32 release candidate depends on the MPL update that has yet to be integrated. There is no reason to hold up branch/release for new features.

Shouldn't we settle now on a realistic branching date and proceed with the release? Or, should I shut my mouth and let the release manager handle this as he deems convenient?

Again, don't get me wrong. I am not willing to push anybody, but the process looks, well, erratic.

Please don't forget that we are all volunteers here. The best way to speed up things is to contribute to them. MPL issues notwithstanding, we still have the regression field to be cleared -- http://www.meta-comm.com/engineering/boost-> regression/developer/summary.html. Turning it green while MPL is in works will make a huge difference.

The only way an MPL update can be expected to not create new issues is it makes only small changes. If that's the case its not worth holding things up for. If the changes are not small, it likely will create a slew of new issues.

...

If you are willing to take over managing that one until the MPL check-in, be my guest.

I wish we could all do as well as Joaquin has been doing in clearing issues related to his library. He has been doing an excellent job. When this topic was discussed at the beginning of the release process, it was indicated that subsequent releases would already be scheduled and would be soon after 1.32 . This was to assure developers that if they missed this release, it wouldn't be a big issue as the next one would be soon anyway. This is still a good idea and should be implemented. So Branch now Release branch available only for bug fixes and test clearing Main branch new MPL and what ever else. Robert Ramey