Hi All, I'm finally ready to start working towards the next release, which as some of you might remember I volunteered to manage. Below is a preliminary schedule what I would like to propose, subject to adjustments as I receive your input: June 24-27: Announce a preliminary release schedule, collect information about everyone's plans for the release, adjust/confirm the schedule, make regression reports to reflect the actual status of the main trunk, setup nighly runs of the inspection report (http://tinyurl.com/2vo5p), construct a "Release Progress" page publishing the milestones, the collective TODO list, and links to all the reports. June 27-July 16: Use regression reports to identify and resolve the outstanding issues with the main trunk. Walk through and deal with all the patches and bug reports submitted to the list/SourceForge tracker since the last release. In accordance with the TODO list, track the progress of individual developers. By July 15, 24:00 US Central Time every line of code that is intended to be put into this release should be in the CVS, and the next round of regression reports should show no regressions against the then-current expected failures markup. July 16: Branch for release. Switch regression tests to run on the branch. July 17-July 18: No code checkins are allowed expect to fix the failures resulted from branching (hopefully none). Documentation checkins are still OK. Perform the rest of the pre-release tasks listed in http://tinyurl.com/2meuh. July 18, 24:00 US Central Time marks a complete freeze of the branch. July 19-July 20: Prepare and test the release candidate archives. Fix any found issues and repeat. July 21: Release according to the http://tinyurl.com/2meuh procedure. As you can see from the first milestone's description, at this point I'd like to collect everybody's plans for the release (for those developers who do plan to do something, of cource), with approximate dates, so that we have a better understanding of how everything is going to fall together. Please post these plans to the list with "[1.32 Plan]" prefix in the subject. As usual, any other comments/suggestions are more than welcome. Thank you! -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy wrote:
As you can see from the first milestone's description, at this point I'd like to collect everybody's plans for the release (for those developers who do plan to do something, of cource), with approximate dates, so that we have a better understanding of how everything is going to fall together. Please post these plans to the list with "[1.32 Plan]" prefix in the subject.
These are the things that I more or less plan for program_options: 1. Add markup for the current failures on Windows. I've done all workarounds I planned. 2. Finally get some results on gcc2.95-stlport. I expect that the library should work there, but due to Boost.Test failure I don't have any results. 3. Try to make Sun compiler happy. I'm comitted a workaround some time ago, but tests on Solaris were not run since then. 4. Check dynamic linking on Windows. - Volodya
Aleksey Gurtovoy <agurtovoy@meta-comm.com> writes:
As you can see from the first milestone's description, at this point I'd like to collect everybody's plans for the release (for those developers who do plan to do something, of cource), with approximate dates, so that we have a better understanding of how everything is going to fall together. Please post these plans to the list with "[1.32 Plan]" prefix in the subject.
There are a couple of things that ideally I would like to handle, but which I am not promising (yet): 1. Minor adjustments to code in the iterators library 2. Iterators library doc fixes 3. Fix numeric_cast - it currently fails to detect some overflows. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
"Aleksey Gurtovoy" <agurtovoy@meta-comm.com> wrote in message news:m2r7s5gva5.fsf@meta-comm.com... [snip] | July 16: | Branch for release. Switch regression tests to run on the branch. | | July 17-July 18: | No code checkins are allowed expect to fix the failures resulted | from branching (hopefully none). Documentation checkins are still | OK. Perform the rest of the pre-release tasks listed in | http://tinyurl.com/2meuh. July 18, 24:00 US Central Time marks a | complete freeze of the branch. It's not that I don't like being busy, but I simply cannot be finished with my work that early---I need at least another week. That said, I believe Pavol can live with an internal version of "boost.range" if he has to, and I have no problem with postponing my two libs another release. br Thorsten
I'm finally ready to start working towards the next release, which as some of you might remember I volunteered to manage.
Can a make a few small suggestions... I could find much mention of these in the list archives, so I apologise in advance if these suggestion offend anyone... Note that this is my first post to the list, and its from a library users' point of view (ie not the library developers POV). And that I'm focusing on Posix'y systems... To allow the autoconf tools (ie configure) to detect the presence of the various Boost libs and header file versions, would it be possible to add a C-linkage function to each libraries' source file(s). This would allow users to add a configure check which detects if a particular library instance is installed. For example, we add the following code to each library instance: extern "C" boost_autoconf() {} This allows autoconf users to add a test to their configure.in script: AC_CHECK_LIB(boost_regex,boost_autoconf,...,[Boost::Regex library not found]) The extern simply needs to be added to one of the top cpp files in each library. Note that I have only focused on Boost::Regex I am unsure if other libraries implement such functionality (the complete Boost API is huge... :) Would it be possible to get bjam to detect the system installed compiler, then if it matched the "-sTOOLS=xxx" name, then it would install a version of the target libraries which doesn't include the compiler name? eg installing Boost results in libraries names like "libboost_signals-gcc.so" - it would be useful to install a library names like "libboost_signals.so". The main reason is that when you build your application, 'make' will use the $(CC) value (which is often 'gcc', 'aCC', 'cc', etc) automatically dependant on the platform - the application doesn't care which compiler it is built with, it only cares that it is the 'default system compiler'. Boost installs its include files in $PREFIX/include/boost-<version>/boost (where prefix is something like /usr/local). Would it be possible to install a symlink which effestively implements: cd $PREFIX/include ln -s boost-<version>/boost boost but only if the symlink didn't already exist. This would allow users to do a default/generic install of Boost, without them need to specify the specific version of the libraries within their build/make system. Finally (if there isn't a technique to do this already), would it be possible for the main boost/config.hpp to include a version number as a #define (or something similar), so the the application build tools could detect the whether the installed version is sufficient. Any comments welcome... Mathew Robertson
Mathew Robertson wrote:
To allow the autoconf tools (ie configure) to detect the presence of the various Boost libs and header file versions, would it be possible to add a C-linkage function to each libraries' source file(s). This would allow users to add a configure check which detects if a particular library instance is installed. For example, we add the following code to each library instance:
extern "C" boost_autoconf() {}
This allows autoconf users to add a test to their configure.in script:
AC_CHECK_LIB(boost_regex,boost_autoconf,...,[Boost::Regex library not found])
I don't see why you need a function with C linkage for this to work. The behavior of autoconf depends on the current language specified in configure.ac at the point where you call AC_CHECK_LIB. If that language is C++, you should well be able to test for functions with C++ linkage. See http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_chapter/autoc...
Finally (if there isn't a technique to do this already), would it be possible for the main boost/config.hpp to include a version number as a #define (or something similar), so the the application build tools could detect the whether the installed version is sufficient.
yeah, that sounds like a good idea. Additionally, autotools based packages often use config/package scripts that can be queried by library users for the required compilation and linking flags (for example additional libraries the application has to link with (such as '-lpthread') when linking with the library in question. Regards, Stefan
To allow the autoconf tools (ie configure) to detect the presence of the various Boost libs and header file versions, would it be possible to add a C-linkage function to each libraries' source file(s). This would allow users to add a configure check which detects if a particular library instance is installed. For example, we add the following code to each library instance:
extern "C" boost_autoconf() {}
This allows autoconf users to add a test to their configure.in script:
AC_CHECK_LIB(boost_regex,boost_autoconf,...,[Boost::Regex library not found])
I don't see why you need a function with C linkage for this to work. The behavior of autoconf depends on the current language specified in configure.ac at the point where you call AC_CHECK_LIB. If that language is C++, you should well be able to test for functions with C++ linkage. See http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_chapter/autoc...
Yeah - thats what I'm trying to do. Specifically, I'm trying to detect if "libboost_regex..." is installed, so I have the following: AC_CHECK_LIB(boost_regex-gcc,<somefunc>,,AC_ERROR([Must have the Boost::Regex library installed]) Now the problem is, 'What do I put in for <somefunc>?' All other C++ libraries I have used, specifically contain a C-linkage function to allow configure to detect it. regards, Mathew Robertson
Mathew Robertson wrote:
For example, we add the following code to each library instance:
extern "C" boost_autoconf() {}
If you add *exactly this* to *each* library, won't you get linker errors when doing static linking, because each boost library will define it's own version of this function? - Volodya
For example, we add the following code to each ^^^^^^^^^^^
library instance:
extern "C" boost_autoconf() {}
If you add *exactly this* to *each* library, won't you get linker errors when doing static linking, because each boost library will define it's own version of this function?
8-/ Mathew
On Thursday 24 June 2004 8:44 pm, Mathew Robertson wrote:
Can a make a few small suggestions...
Suggestions are *always* welcome.
To allow the autoconf tools (ie configure) to detect the presence of the various Boost libs and header file versions, would it be possible to add a C-linkage function to each libraries' source file(s). This would allow users to add a configure check which detects if a particular library instance is installed. For example, we add the following code to each library instance:
extern "C" boost_autoconf() {}
This allows autoconf users to add a test to their configure.in script:
AC_CHECK_LIB(boost_regex,boost_autoconf,...,[Boost::Regex library not found])
The extern simply needs to be added to one of the top cpp files in each library.
As Vladimir points out, we'll need to include the name of the lib in that, e.g., boost_regex_autoconf or boost_threads_autoconf.
Would it be possible to get bjam to detect the system installed compiler, then if it matched the "-sTOOLS=xxx" name, then it would install a version of the target libraries which doesn't include the compiler name? eg installing Boost results in libraries names like "libboost_signals-gcc.so" - it would be useful to install a library names like "libboost_signals.so". The main reason is that when you build your application, 'make' will use the $(CC) value (which is often 'gcc', 'aCC', 'cc', etc) automatically dependant on the platform - the application doesn't care which compiler it is built with, it only cares that it is the 'default system compiler'.
bjam doesn't seem to have the notion of a "system compiler", but it seems that we could have an "install-as-system" step that would do this.
Boost installs its include files in $PREFIX/include/boost-<version>/boost (where prefix is something like /usr/local). Would it be possible to install a symlink which effestively implements:
cd $PREFIX/include ln -s boost-<version>/boost boost
but only if the symlink didn't already exist. This would allow users to do a default/generic install of Boost, without them need to specify the specific version of the libraries within their build/make system.
Sounds like a good idea...
Finally (if there isn't a technique to do this already), would it be possible for the main boost/config.hpp to include a version number as a #define (or something similar), so the the application build tools could detect the whether the installed version is sufficient.
You want boost/version.hpp, which defines the BOOST_VERSION and BOOST_LIB_VERSION macros for this purpose. The file itself describes the (simple) encoding used. Doug
Hi, On Thu, Jun 24, 2004 at 04:28:02AM -0500, Aleksey Gurtovoy wrote: [snip]
July 17-July 18: No code checkins are allowed expect to fix the failures resulted from branching (hopefully none). Documentation checkins are still OK. Perform the rest of the pre-release tasks listed in http://tinyurl.com/2meuh. July 18, 24:00 US Central Time marks a complete freeze of the branch.
July 19-July 20: Prepare and test the release candidate archives. Fix any found issues and repeat.
July 21: Release according to the http://tinyurl.com/2meuh procedure.
As you can see from the first milestone's description, at this point I'd like to collect everybody's plans for the release (for those developers who do plan to do something, of cource), with approximate dates, so that we have a better understanding of how everything is going to fall together. Please post these plans to the list with "[1.32 Plan]" prefix in the subject.
As usual, any other comments/suggestions are more than welcome.
I have few outstanding issues to fix, but they are mostly related to the documentation. I think, I can manage it. As it seems, that the Range library will not make it to this release, I will use the internal versions of facilities that are currently in the string_algo lib. So my todo list is as follows: 1) Finish the documentation - Add functions list - Add exception specifications - Cleanup 2) Fix examples 3) If there will be time, improve find_iterator 4) Fix possible regressions. Questions: - I have posted some requestes/bugs on the boost-doc list. What is the status of this. Will they be fixed before release? - According to metacom's tables regex is failing on comeau a so string_algo regex test. Is this a setup or regex problem? - There is an problem with Intel compiler, split tests are failing and I cannot figureout why. The message is very vague. Could somebody with an access to this platform, try to debug the cause of the problem? - In regards to the older compiler support. I cannot resonably support compilers, that I don't have an access to. Therefor if somebody is interested to use string_algo library with one of such compilers, I will need an active help with porting. Regards, Pavol
Pavol Droba ha escrito:
- There is an problem with Intel compiler, split tests are failing and I cannot figureout why. The message is very vague. Could somebody with an access to this platform, try to debug the cause of the problem?
The problem is with the call to split( vtokens, str1, is_any_of("x"), token_compress_on ); I haven't been able to analyze it thoroughly, but I'd say that the problem has to do with the fact that Dinkumware's std::vector (in the somewhat old version shipped with VC6 and shared by Intel compiler) does *not* have a range constructor of the form template<class InIt> vector(InIt first, InIt last, const A& al = A()); but instead provides the non-template version: vector(const_iterator first, const_iterator last, const A& al = A()); In case you want to reproduce this scenario, you might try editing your stdlib source code so as to reproduce the same situation. HTH Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
On Fri, Jun 25, 2004 at 12:51:42PM +0200, Joaqu?n M? L?pez Mu?oz wrote:
Pavol Droba ha escrito:
- There is an problem with Intel compiler, split tests are failing and I cannot figureout why. The message is very vague. Could somebody with an access to this platform, try to debug the cause of the problem?
The problem is with the call to
split( vtokens, str1, is_any_of("x"), token_compress_on );
I haven't been able to analyze it thoroughly, but I'd say that the problem has to do with the fact that Dinkumware's std::vector (in the somewhat old version shipped with VC6 and shared by Intel compiler) does *not* have a range constructor of the form
template<class InIt> vector(InIt first, InIt last, const A& al = A());
but instead provides the non-template version:
vector(const_iterator first, const_iterator last, const A& al = A());
In case you want to reproduce this scenario, you might try editing your stdlib source code so as to reproduce the same situation.
Thanks, This might be one of the problems, but, there is probably something else as well. In vc6 emulation mode, Intel compiler is not working at all with the string_algo lib. But this test is also failing when stlport is used. And the error is run-time, not compile time, therefor I'm puzzled since I don't have any output from tests. I have to figure out some way how to track down the problem. Pavol.
On Friday 25 June 2004 2:57 am, Pavol Droba wrote:
- I have posted some requestes/bugs on the boost-doc list. What is the status of this. Will they be fixed before release?
I'll try! Getting unrelated C++ bits working (Function, Signals, Graph) comes first, but I'll try to get to all of the BoostBook issues resolved. Doug
Aleksey Gurtovoy <agurtovoy@meta-comm.com> wrote:
Hi All,
I'm finally ready to start working towards the next release, which as some of you might remember I volunteered to manage. Below is a preliminary schedule what I would like to propose, subject to adjustments as I receive your input:
Since it has been awhile, has there been any progress on the licensing issues for the graph library? The last thing I heard on this list is that it was being worked on. Is that still true? Cheers, Walter Landry wlandry@ucsd.edu
"Aleksey Gurtovoy" wrote:
June 24-27: Announce a preliminary release schedule, collect information about everyone's plans for the release, adjust/confirm the schedule,
I asked Jan Galdun and he will try to make circular_buffer available for 1.32.
July 16: Branch for release. Switch regression tests to run on the branch.
Seeing all the sudden the rush, a week delay may be considered. /Pavel
"Pavel Vozenilek" <pavel_vozenilek@hotmail.com> wrote in message news:cbm01d$30k$1@sea.gmane.org... | | "Aleksey Gurtovoy" wrote: | > July 16: | > Branch for release. Switch regression tests to run on the branch. | > | Seeing all the sudden the rush, a week delay may be considered. If so I will probably also be able to get Boost.Range finshed for this release. But I need to know if we get another week or not. br Thorsten
"Thorsten Ottosen" <nesotto@cs.auc.dk> writes:
"Pavel Vozenilek" <pavel_vozenilek@hotmail.com> wrote in message news:cbm01d$30k$1@sea.gmane.org... | | "Aleksey Gurtovoy" wrote:
| > July 16: | > Branch for release. Switch regression tests to run on the branch. | > | Seeing all the sudden the rush, a week delay may be considered.
If so I will probably also be able to get Boost.Range finshed for this release. But I need to know if we get another week or not.
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. How come we have so many accepted libraries that have not even been put in the CVS? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
On Sun, 27 Jun 2004 08:53:29 -0400, David Abrahams wrote
I'd like to know the reasons for "all the sudden rush". We did
I agree with Dave on this -- the release was advertised ages ago. 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. One reason I believe this is that it is unfair to the people graciously volunteering their time to manage the release -- being in limbo for 2 months is a big burden. There is also a higher load on the folks running regression tests. 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.
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. How come we have so many accepted libraries that have not even been put in the CVS?
I think there are 2 factors here. 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. 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. BTW, I've been very busy lately, but I noticed that the reviews seem to have ground to a halt again -- I haven't pinged Mr. Witt, but we seem to have lost focus on working off the review backlog. Jeff
On Jun 27, 2004, at 10:30 AM, Jeff Garland wrote:
BTW, I've been very busy lately, but I noticed that the reviews seem to have ground to a halt again -- I haven't pinged Mr. Witt, but we seem to have lost focus on working off the review backlog.
I don't think we can clear the review backlog and pull together a release at the same time. Let's let the review queue idle until we get 1.32.0 out the door. Doug
On Sun, 27 Jun 2004 10:52:31 -0500, Doug Gregor wrote
On Jun 27, 2004, at 10:30 AM, Jeff Garland wrote:
BTW, I've been very busy lately, but I noticed that the reviews seem to have ground to a halt again -- I haven't pinged Mr. Witt, but we seem to have lost focus on working off the review backlog.
I don't think we can clear the review backlog and pull together a release at the same time. Let's let the review queue idle until we get 1.32.0 out the door.
No problem with that, but we stalled out on the reviews prior to the release effort kicking into high gear. I'm hoping that if we can stick to the outlined schedule the pause won't be long, but past boost releases don't inspire confidence. I don't want to see a 2 month pause in the reviews. Which is part of why I feel strongly that we should hold as closely to the outlined 1.32 release schedule as possible. Jeff
On Jun 27, 2004, at 11:28 AM, Jeff Garland wrote:
On Sun, 27 Jun 2004 10:52:31 -0500, Doug Gregor wrote
On Jun 27, 2004, at 10:30 AM, Jeff Garland wrote:
BTW, I've been very busy lately, but I noticed that the reviews seem to have ground to a halt again -- I haven't pinged Mr. Witt, but we seem to have lost focus on working off the review backlog.
I don't think we can clear the review backlog and pull together a release at the same time. Let's let the review queue idle until we get 1.32.0 out the door.
No problem with that, but we stalled out on the reviews prior to the release effort kicking into high gear.
I was just starting to get worried about that, too :(
I'm hoping that if we can stick to the outlined schedule the pause won't be long, but past boost releases don't inspire confidence. I don't want to see a 2 month pause in the reviews. Which is part of why I feel strongly that we should hold as closely to the outlined 1.32 release schedule as possible.
Well, this release is rather important to at least several Boosters, so it might just happen. Say, have you looked at the MetaComm Date-Time regression results recently <g>? Doug
On Sun, 27 Jun 2004 13:32:55 -0500, Doug Gregor wrote
Well, this release is rather important to at least several Boosters, so it might just happen. Say, have you looked at the MetaComm Date- Time regression results recently <g>?
No, not recently, but I know there are some regressions from 1.31. I have some changes in the works that I expect to check in over the next couple days that will likely impact that. Anyway, I expect to be able to take care of those easily prior to the branch-for-release. Also, there are probably a couple of 'expected regressions' that I will need to document. That is, there were some date-time tests where I was removing the tests for a compiler that would have failed. Unfortunately, that covers-up the non-support of the compiler / platform . And while I'm on the subject date-time plans for release, the only 'major issue' for this release is whether we are switching to boost-book for this release. We would like to, but if we don't make it we will do it for the next release. One thing that would help a bit (although I think we've mostly worked around it) is if you could reply to this question on the boost-doc list ;-) http://sourceforge.net/mailarchive/forum.php?thread_id=4960807&forum_id=13340 Jeff
"Jeff Garland" <jeff@crystalclearsoftware.com> wrote in message news:20040627153020.M97518@crystalclearsoftware.com... | On Sun, 27 Jun 2004 08:53:29 -0400, David Abrahams wrote | > I'd like to know the reasons for "all the sudden rush". We did | | I agree with Dave on this -- the release was advertised ages ago. 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. Understandable. I'm just asking so I know if I should use some time in my vacation or not. If there is no extra week, I see no reason for doing those preparations. | > 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. How come we have | > so many accepted libraries that have not even been put in the CVS? [snip] | The other thing that seems to be a | pattern is that libraries get accepted, then authors get a list of changes to | make. 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. At least in my case that has been the situation. I'm the one to blame for not getting a post-review out sooner, but I never really seemed to have the weekend that it would take to do so. Then exams hit, and soon I'm moving back home and travelling a bit. br Thorsten
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
I think there are 2 factors here. 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. 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.
Should we have accepted libraries checked in immediately (on a branch, maybe?), and then only added to the libs page when the authors deem them ready? If they're checked in on the trunk they can even get the benefit of regression testing while the authors whip them into shape. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
On Sun, 27 Jun 2004 16:35:15 -0400, David Abrahams wrote
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
I think there are 2 factors here. 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. 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.
Should we have accepted libraries checked in immediately (on a branch, maybe?), and then only added to the libs page when the authors deem them ready?
I think that's an excellent suggestion. The only time we might not want to do that is if major file renaming is required -- that is a bit clunky with CVS. But in general, I think most of the recent submissions have been developed with boost guidelines up-front and so will just drop in. As for the branch, that complicates the process a bit, but it has the advantage that none of the new library files would appear in the release if they aren't ready. I can imagine a couple of ways: 1) an alpha_lib branch which covers all accepted, but not ready for prime-time libs or 2) one branch per library. Nice thing about the second approach is that the branch naturally obsoletes when the library is put on the trunk. But it does make it harder to get all the 'alpha libs' checked out into a tree.
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, this is a big advantage -- fixing platforms / compilers you don't have is a slow process. If we use a branch, maybe we could get the regression folks to include some alpha libraries when we aren't in the release shakedown phase. But, honestly, I think we should go for it either way. I've been using some of these alpha-libraries so it would make my life easier if they were in the repository. One last thought. If we make this the policy we could go ahead and put some of these libraries in the tree before the 1.32 release. If they are sufficiently stable (which I expect some like circular_buffer to be -- I'm using it on 3 platforms now) they can go in the release. If they aren't we can just leave them out. Jeff
Jeff Garland wrote:
Should we have accepted libraries checked in immediately (on a branch, maybe?), and then only added to the libs page when the authors deem them ready?
I think that's an excellent suggestion. The only time we might not want to do that is if major file renaming is required -- that is a bit clunky with CVS. But in general, I think most of the recent submissions have been developed with boost guidelines up-front and so will just drop in.
There's a question, though: what if review manager says "accepted provided this feature is added before adding to CVS". This what happened with program_options and Unicode support, and actually, the Unicode support took most of the post-review time. OTOH, I'm not sure there's a procedure which makes sure that all/some review comments are addressed, so maybe immediate checking is no worse than the current practice. - Volodya
"David Abrahams" <dave@boost-consulting.com> wrote in message news:u4qowivss.fsf@boost-consulting.com... | Should we have accepted libraries checked in immediately (on a branch, | maybe?), and then only added to the libs page when the authors | deem them ready? | | If they're checked in on the trunk they can even get the benefit of | regression testing while the authors whip them into shape. good idea. I think Pavol would appreciate that with boost.range. br Thorsten
Somewhere in the E.U., le 29/06/2004 Bonjour I will be on vacation from tomorrow until July the 22nd (first time I had so much vacation at once in about 15 years :-) ), and totally off-line during that time. I have not had the time to do what I had hoped for this release (yet again :-< ). So the timeline looks fine to me. Thank you for your effort. I will do more work for the next release (I really *must*). Merci Hubert Holin In article <m2r7s5gva5.fsf@meta-comm.com>, Aleksey Gurtovoy <agurtovoy@meta-comm.com> wrote:
Hi All,
I'm finally ready to start working towards the next release, which as some of you might remember I volunteered to manage. Below is a preliminary schedule what I would like to propose, subject to adjustments as I receive your input:
June 24-27:
[SNIP]
July 21: Release according to the http://tinyurl.com/2meuh procedure.
As you can see from the first milestone's description, at this point I'd like to collect everybody's plans for the release (for those developers who do plan to do something, of cource), with approximate dates, so that we have a better understanding of how everything is going to fall together. Please post these plans to the list with "[1.32 Plan]" prefix in the subject.
As usual, any other comments/suggestions are more than welcome.
Thank you!
participants (14)
-
Aleksey Gurtovoy -
David Abrahams -
Doug Gregor -
Hubert Holin -
Jeff Garland -
Joaquín Mª López Muñoz -
John Maddock -
Mathew Robertson -
Pavel Vozenilek -
Pavol Droba -
Stefan Seefeld -
Thorsten Ottosen -
Vladimir Prus -
Walter Landry