Eric Niebler wrote:

Beman Dawes wrote:

...

There has been little feedback on the 1.40.0 beta release. I'm hoping that is a good sign:-)

Unless someone objects, I'll start building the actual release in an hour or so.

What ever happened to 1.39?

Nobody ever got back to me about this issue: http://groups.google.com/group/boost-developers-archive/msg/875d10cf81244de0

Hmm. I wonder if this issue was ever considered by release management team, and explicitly declared as not a release blocker? Do we even have a mechanism to submit possible release blocker issues for consideration, and a Trac query to search for such? Speaking about the issue, the backtrace seem to say Boost.Jam is happily working executing something. 1. For how long did you let Boost.Jam run? If you wait 30 mins, does it finish? 2. If not, can you run with -d+5 option, let it run for as long as possible, and send me last 5000 lines of the output? Note that the output may be long, so "as long as possible" probably means "before your run out of disk space". - Volodya

Beman Dawes wrote:

On Mon, May 4, 2009 at 4:57 AM, Vladimir Prus <vladimir@codesourcery.com> wrote:

...

Eric Niebler wrote:

...

Beman Dawes wrote:

...

There has been little feedback on the 1.40.0 beta release. I'm hoping that is a good sign:-)

Unless someone objects, I'll start building the actual release in an hour or so.

What ever happened to 1.39?

Nobody ever got back to me about this issue: http://groups.google.com/group/boost-developers-archive/msg/875d10cf81244de0

Hmm. I wonder if this issue was ever considered by release management team, and explicitly declared as not a release blocker?

I followed the discussion, and thought that it had been resolved and fixed.

...

Do we even have a mechanism to submit possible release blocker issues for consideration, and a Trac query to search for such?

Not that I know of. Might be a good idea. Do you have a suggestion as to how it might work?

Maybe, Trac query for issues with milestone of <next release> and severity of "Showstopper". I've just looked for 1.39 issues -- there's 155 open ones, presumably because sumbitters tend to set some value for "Milestone". Of them, 9 are marked as showstoppers -- presumably by submitters to. So, it's safe to assume that only a minority of issues submitted by users will have severity of "Showstopper" and therefore it's a good way to indicate that an issue should be considered by release team. - Volodya

2009/5/1 Beman Dawes <bdawes@acm.org>:

OK, go ahead and merge. Also, you'll need to rebuild the docs so I pickup an updated copy from the ftp site.

Ok, I'll do that. Daniel

On Sat, May 2, 2009 at 1:39 PM, Daniel James <daniel_james@fmail.co.uk> wrote:

2009/5/2 Beman Dawes <bdawes@acm.org>:

...

OK, the release packages are built and up at http://boost.cowic.de/rc/

To clarify: despite the topic being "[1.40.0] OK to build release?", this is actually about the 1.39.0 release? Thanks, Eugene Wee

Neal Becker wrote:

...

OK, try again. This time clean .tar.bz2.

sh BUILD warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. Note: Building Boost.Regex with Unicode/ICU support enabled Using ICU in /usr/include /usr/local/src/boost_1_39_0_beta1/tools/build/v2/build/virtual- target.jam:1056: in virtual-target.register-actual-name from module virtual- target error: Duplicate name of actual target: <pstage/lib>libboost_date_time.so.1.39.0 ... error: added properties: <threading>multi error: removed properties: <threading>single

This is expected. In 1.39, --layout=system does not use any decoration of

names, so that to match it's intended purpose -- system integrators. You are trying to build both ST and MT variants and put both to 'stage'

Has this issue been addressed? the directory,

which results in name clash.

I can introduce new --layout=tagged that would encode threading and variant into the name. What do you think?

- Volodya

On Mon, May 4, 2009 at 4:49 AM, Vladimir Prus <vladimir@codesourcery.com> wrote:

No, it was not. Lacking any posted schedule, I did not expect final release this weekend. To clarify, original schedule on http://www.boost.org/development/index.html has two weeks between beta and release. In fact, beta was released on April 24, with final release on May 3 -- which is considerably shorter.

The intermediate dates in the schedule are relatively flexible, and we often adjust them. For example, to take weekends into account. Slippage in the intermediate dates doesn't mean the final target date slips. --Beman

2009/5/1 Robert Ramey <ramey@rrsd.com>:

...

I've got a couple of changes that I'd like to merge:

https://svn.boost.org/trac/boost/changeset/52665/trunk

This change removes the google analytics from the pre-built docs. I could see doing this.  It does have the potential for making the release manager's life a little more painful.

In case you didn't know, I manage the documentation. If you look in the archives you'll find that I'm going to work on a longer term solution. I've been emailled the necessary doxygen files of list, but it'll take me a little while to get them working and in place.

 The REAL fix is to boost documentation build upto snuff so that the user could be confident that he can build the docs on sight.  For uses who can't do this, the docs could be provided as a separate download.

This documentation isn't part of the documentation build.

...

https://svn.boost.org/trac/boost/changeset/52674/trunk

This changes code that is subject to testing. To merge a change like this which hasn't been tested against the release branch would seem to me to be a really bad idea. What is the downside of not including this for a few months until the next release?

Poor performance if more than about 2 millions elements are in an unordered container. It isn't a show stopper but the change isn't at all disruptive and it's certainly correct. It won't affect any other libraries. I certainly wouldn't change hash at this point. Daniel

Eric Niebler wrote:

Vladimir Prus wrote:

...

Beman Dawes wrote:

...

There has been little feedback on the 1.40.0 beta release. I'm hoping that is a good sign:-)

Or users just don't do anything until it's really-really-final tarball :-( We've just got a bug report on boost-users:

http://permalink.gmane.org/gmane.comp.lib.boost.user/47346

that say that install, on Linux, does not work, unless you specify --libdir option explicitly. 'stage' is not affected.

I am very sorry for letting this slip, but the question is what to do now. I've already fixed the problem on trunk:

https://svn.boost.org/trac/boost/changeset/52754

How do we make this available to users?

1. Is release branch open now for all commits?

Beman?

...

2. It is desirable to create new set of packages, with fixed version of bootstrap.sh? Alternatively, should it be in some 'hot-fix' area?

IMO, this issue is serious enough to justify a point release. Here's what I'd like to see:

- We create a 1.39.1 branch from the 1.39 tag. - We merge the patched bootstrap.sh to the 1.39.1 branch - We issue a new release from that branch

Also,

*** here is one man's opinion. I'm concerned that this would take up a lot of time on the release manager's part. I propose something simpler. create a tag on 1.39.0 - if it's not created already. Check in this "critical" change. (I'm assuming there is some sort of consensus that is a showstopper for people). create a tag on the release branch called 1.39.1 at this point, the issuse of if/when/how to distribute a "point release" can be separate to any other issues. It would also be nice of something could be added to the build test suite that would have detected this earlier. Robert Ramey As

- We open the normal release branch for general merges and start work on 1.40.

Opinions?

2009/5/8 Vladimir Prus <vladimir@codesourcery.com>:

I have said, it should not require more that (1) downloadining current packages (2) replacing a single file (3) uploading new ones.

While (3) is messy with sourceforge, it's probably about 10 mins overall.

There's a little more to it than that. I'll need release notes (just a paragraph in plain text would do) for the release so I can put the announcement on the website. The version number appears in the source in a few places. So that should probably be updated as well, the details are at: https://svn.boost.org/trac/boost/wiki/ReleasePractices/ManagerCheckList (the whole page should really be reviewed - I might have missed something out). It would be better if the release scripts were used, although I think they're hardcoded to use the release branch. If they are used then I'll need to set up the files that are downloaded by the release script (that won't take long, once I've been given the release notes). If they aren't used then README.txt will need to be updated as well (it's normally generated as part of the release process). Also, once it's all finished, Beman or Rene will need to upload the zipfile to the server. Since the documentation should be almost identical to 1.39.0, that doesn't have to be done immediately. We should also try to get people to try out the build system on as many platforms as possible before finalizing the release. Daniel

I think this is fixed in the trunk but hasn't been merged into the release. Am I wrong about this? Robert Ramey Vladimir Prus wrote:

FWIW, at least one other important issue seems to have fallen through the cracks:

https://svn.boost.org/trac/boost/ticket/2947 serialization/throw_exception.hpp uses BOOST_NO_EXCEPTIONS in the wrong way

This is affecting KDE, and fix in on the trunk, just on in release branch.

- Volodya

On Thu, May 7, 2009 at 1:45 PM, Eric Niebler <eric@boostpro.com> wrote:

...

1. Is release branch open now for all commits?

Beman?

Yes, for 1.40.0. But that doesn't stop us from also working on either a hot fix or a proint release.

...

2. It is desirable to create new set of packages, with fixed version of bootstrap.sh? Alternatively, should it be in some 'hot-fix' area?

IMO, this issue is serious enough to justify a point release. Here's what I'd like to see:

- We create a 1.39.1 branch from the 1.39 tag. - We merge the patched bootstrap.sh to the 1.39.1 branch - We issue a new release from that branch

Yep, that would work.

Also,

- We open the normal release branch for general merges and start work on 1.40.

That's done for 1.40.0. Once a release ships, it is often a week or so before I get to that. But there is no reason some other release manager couldn't do it as soon as a release ships. See https://svn.boost.org/trac/boost/wiki/ReleasePractices/ManagerCheckList#Rele... for the steps involved. --Beman