- Boost - lists.boost.org

Re: 1.32 release preparation
by Johannes Brunen 28 Jun '04

28 Jun '04

On Sun, 27 Jun 2004 16:35:15 -0400, David Abrahams wrote > Should we have accepted libraries checked in immediately (on a branch, > maybe?), Maybe we should reconsider the meaning of 'acceptance' in the review process. Apart of that, I think that this is a very good idea. > and then only added to the libs page when the authors > deem them ready? We should list them on the lib page but in a special section. > If they're checked in on the trunk they can even get the benefit of > regression testing while the authors whip them into shape. Yes, that would be fine. With best regards Johannes

2 1

Re: [boost] Re: 1.32 release preparation
by Johannes Brunen 28 Jun '04

28 Jun '04

On Sun, 27 Jun 2004 08:30:20 -0700, Jeff Garland wrote: > As much as I'd like to see circular_buffer, serialization, etc in this release I'd rather > see us pull off a release that doesn't take 2-3 months to accomplish. I > believe we should hold the line on the schedule now and anything that isn't > ready should simply go in the next release. I disagree on that. We don't have that many Boost releases. Waiting for the next one could be a long time. Therefore, I propose to wait until all (or as many as possibly considering a reasonable time schedule) accepeted libraries will be checked into CVS and be part of the release. > And if there are a large > number of new things left out by that approach then we should plan another > release sooner rather than waiting 4 months. However, then you need new volunteers which have to spend the time for the whole procedure again. > One is that we have been reviewing and > accepting a large number of libraries recently. So, many of these have been > accepted in the last couple months. The other thing that seems to be a > pattern is that libraries get accepted, then authors get a list of changes to > make. I could think of a review process which accepts a library only after the list of requested changes has beem made. > If they get busy it often takes months to get these done and then > finally they check into CVS. So a release tends to trigger the evaluation of > anything that is in that multi-month pipeline. That isn't good. I would prefere a review process which leads to final acceptance only after a library is 'CVS' compatible i.e. does not yield to any (known) regressions of the existing pool libraries and is equipted with a working testing facility. With best regards Johannes

2 1

Re:[boost] Re: 1.32 release preparation
by Robert Ramey 28 Jun '04

28 Jun '04

Dave Abrahams wrote: >I'd like to know the reasons for "all the sudden rush". We did >announce a schedule long ago, and it has already been delayed by three >weeks. I'm not asking in order to point fingers; I just want to know >how to avoid the "sudden rush" next time. Here is the current scenario. a) The announcement gets posted - release 1.32 scheduled for date x. b) Each developer decides - uh oh I better get in my changes before date x. c) Of course these changes take longer d) and break some other things e) which takes longer still Personally I think the concept of scheduling a release fundamentally flawed. I would suggest another idea. a) the release manager or the core influential developers keep an eye on the current state of the CVS tree and tests. b) When things look "pretty good", branch for release without warning. None of this loading my latest feature in to make the schedule. c) the Main tree goes on as usual d) pending issues in the release branch are addressed by nagging the person responsible. e) the new version is releases with a number like 1.31.1 or maybe even 28 July 2004. f) any changes between branch and release should be just bug fixes which can then be merged back into the development tree. Under this system, releases would occur more frequently - on the order of 6 weeks. If you're ready to check in your latest feature and the new release branch catches you with your pants down - well too bad. But it's no big deal because the next release will be in 6? weeks anyhow which is close to what its going to take to shake out the repercussions of your check in anyway. I realize that this is not the most orthodox way of doing things. But I think it's really hard to get such a large number of people working independently on exactly the same schedule. >How come we have so many >accepted libraries that have not even been put in the CVS? Almost all libraries are accepted subject to some changes being made. Many such changes seem simple but end up rippling through the whole library. This takes time. Once a library is accepted, then one can get serious about making it pass with a larger number of compilers. This also takes time - a lot of time These changes end up having a ripple effect and can result it changes like moving things in namespaces and subdirectories. While this is going on, the system is broken and really not suitable to be subject to the daily testing routine. So it seems attractive to deal with all this stuff before one does the initial check in to CVS. This way one can start with a relatively clean start. Robert Ramey

6 6

Problems compiling regex with gcc3 on aix and hpux
by Goetz Isenmann 28 Jun '04

28 Jun '04

Hi! I get ugly warnings (they look dangerous to me) when I compile boost/regex on AIX and HP-UX with gcc. On Linux and FreeBSD everything is fine. For example /usr/local/gcc-3.3.3/bin/g++ -c -I. libs/regex/src/cregex.cpp compiles without any complains. On aix43 and hpux11 this gives me the attached warning messages. The order of the messages is slightly different on both platforms, but after sorting the output is identical. I use boost-1.31.0 and see no differences with and without boost-1.31.0-regex-patch-20040503. -- Goetz Isenmann

2 3

Provisional schedule for Boost-1.33
by John Maddock 28 Jun '04

28 Jun '04

Booster's: It's apparent that several of us will just miss the 1.32 deadlines, and I'm sure some people will be concerned when their code will get released as a result, so provisionally I'd like to propose a schedule for 1.33 so we all know where we are. Unless someone else would like to volunteer (and please don't be shy in doing so!), then I guess that means I've just volunteered to manage the release.... Regards, John Maddock. Provisional 1.33 release schedule: ~~~~~~~~~~~~~~~~~~~~~~ Mon 30th August 2004 [1]: ~~~~~~~~~~~~~~~~ Deadline for additions and changes (other than patches to known issues, and docs) to core Boost libraries [2]. Deadline for the addition of new libraries to cvs unless they pass all tests with the core compiler set [3]. Mon 13th September 2004: ~~~~~~~~~~~~~~~~~~ Deadline for additions and changes (other than patches to regressions, and docs) to all Boost libraries. Deadline for all new library additions. Mon 27th September 2004: ~~~~~~~~~~~~~~~~~~ Branch for release, no changes to the release branch without the release managers permission (except for docs). Mon 4th October 2004: ~~~~~~~~~~~~~~~~ First release candidate published, actual release will be as soon as possible thereafter. Notes: ~~~~ 1) There should be a few reminders of this deadline in the weeks beforehand. 2) The core Boost libraries are those that other Boost libraries heavily depend upon: bind config (unless change is restricted to a single compiler, and can be tested with all effected versions of that compiler before commit). enable_if. integer. iterators (the construction framework subset only). mpl operators preprocessor smart_ptr's static_assert test type_traits. 3) The core compiler set includes those compilers that are known to be highly conforming, and for which no failures will normally be expected: gcc 3.3 or later on Linux. Visual C++ 7.1 on Win32. Intel C++ 8 on Win32 or Linux.

1 0

Re: 1.32 release prepar
by Robert Ramey 28 Jun '04

28 Jun '04

Last time we ended up making a release candidate which isolated a couple of final issues. Maybe this is a symptom and maybe it points in the direction of an interesting idea. New code is checked in and tested in the development tree just as it is now. Regression testing and everything remains exactly as it is. Code that documents all test failures and is considered ready for release is moved to the Release Candidate tree. The exact same regression testing setup used on the development tree is used here. Presumably, it would be run much less as things would only be checked in when thought to be perfect which is an infrequent occurrence. Developers develop against the Release Candidate tree. When they have something they like, the check into the Main Development tree as they do now. Traffic on the main development tree is the same as it is now. The Release Candidate Tree should be ready for "shipment" at any convenient time. This basically should consist of assignation of a version number to the tree state. It would not be or scheduled event dramatic event. It could happen as frequently as is convenient. Of course a test failure on the RC tree would be dramatic event. The check in causing such an event could be cast from the RC Tree (Heaven) back into the Main Development Tree (Purgatory) and the author would suffer the attendant embarrassment. Hopefully this would be an infrequent event. I realize that I haven't personally had a library go through the release process so feel free to ignore this idea. Robert Ramey

2 1

[config] about BOOST_NO_POINTER_TO_MEMBER_TEMPLATE_PARAMETERS
by Joaquín Mª López Muñoz 28 Jun '04

28 Jun '04

In config/intel.hpp, this defect macro is defined as follows #if defined(__ICL) && (__ICL <= 710) # define BOOST_NO_POINTER_TO_MEMBER_TEMPLATE_PARAMETERS #endif The macro should be defined *only* for Intel C++ 7.1 or older for Windows 32-bit. So my questions are: 1. Is the definition correct in light of what I said above? 2. What's the meaning of all those different macros __ICC, __ICL and __ECC? I've googled for them but found nothing conclusive. Thanks Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 4

RE: Boost.Threads: RW mutexes and locks.
by Batov, Vladimir 28 Jun '04

28 Jun '04

John Torjo wrote: > Batov, Vladimir wrote: >> >> class writer_lock : public boost::mutex::scoped_lock >> { >> typedef boost::mutex::scoped_lock super; >> >> public: >> >> writer_lock(rw_mutex& mutex) : super(mutex.mutex_), mutex_(mutex) >> { >> ++mutex_.num_writers_; // Make new readers wait. > ^^^^ > > just curios, shouldn't this be thread-safe? I believe it is thread-safe as writer_lock currently inherits from scoped_lock and, consequently, we get inside the writer_lock constructor after its base-class scoped_lock constructor. The base-class constructor does the synchronization.

1 0

store a boost::bind
by Nico Massi 27 Jun '04

27 Jun '04

Hi, Is it possible to store a boost::bind? boost::bind<int> x( f, _1, _2 ); int i = x( 3, 4 ); I get errors if i want to declare a variable of type boost::bind. The point is: I want to have an object that gets a boost::bind, stores it and executes it with the correct values to the time i want. How can i do this? Ciao

4 6

[1.32 Plan] Any date for new version of MPL
by JOAQUIN LOPEZ MU?Z 27 Jun '04

27 Jun '04

Any tentative date for the new version of MPL making it into the CVS? Specially if we stick to July 21st a the release date, I'm concerned that the new MPL will have us fixing regressions for quite a few weeks. OTOH, maybe the update is smooth enough and not many problems arise, but it'd be good to know. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0