Re: [boost] Re: Boost 1.31 release?
Beman Dawes wrote: Assuming I'm release manager for 1.31.0, I'm going to publish explicit release criteria for key platform/compiler pairs. Basically, the release criteria will be 100% accounting for all failures on those platform/compiler pairs. I assume that Linux/GCC will be one of those platform/compiler pairs. I need input from Linux/GCC experts as to which version of GCC should be used for the release criteria. I see GCC 3.3.1 has just been released, and so will be switching the Windows/GCC tests to use that version. Unless anyone objects, it will be one of the Windows release criteria compilers. I added gcc-3.3.1 to the Linux tests for CVS HEAD. Test failures have been down to 1% for gcc versions 3.2.3 and 3.3 a few weeks ago. I think 3.2.3 and 3.3.1 would be good candidates for being release criteria. 6 tests fail for 3.2.3 and 6 tests fail for 3.3.1 From the list I recently posted 1 failure has been fixed and 1 failure is due to a compiler error and not considered harmful. That leaves function::sum_avg_portable math::octonion_test math::quaternion_test test::errors_handling_test to be fixed or to be explained. Note, all these tests fail for both CVS HEAD and RC_1_30_0. Regards, m PS: The one additional error gcc 3.2.3 produces over 3.3.1 is in crc_test, btw. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
At 05:12 AM 8/11/2003, Alisdair Meredith wrote: Aleksey Gurtovoy wrote: While I totally support the failures markup goal, I would like to see _the_ release criteria to include no regressions from the previous release item as well, preferrably for all non-beta compilers that are currently under regression testing. Especially since now we have tools to ensure it. OTOH, it might not always be achievable. For boost 1.31 we are having an interface breaking change to the iterator_adaptors, and not all compilers pass all tests with the new adaptors yet. While this may not be a problem for the iterators library (it is effectively new) it may have a knock-on effect on any other boost libraries implemented on top of it. The principle is a good one, but I be prepared to make a few allowances in the practice. I think a reasonable goal is that any regressions should be understood and discussed, rather than silent. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
At 04:11 PM 8/10/2003, Martin Wille wrote: I added gcc-3.3.1 to the Linux tests for CVS HEAD. Test failures have been down to 1% for gcc versions 3.2.3 and 3.3 a few weeks ago. I think 3.2.3 and 3.3.1 would be good candidates for being release criteria. OK, let's use 3.2.3 and 3.3.1 as the Linux release criteria. Since someone has to research every failure, and this is our first release using formal criteria, we don't want to go overboard. 6 tests fail for 3.2.3 and 6 tests fail for 3.3.1 From the list I recently posted 1 failure has been fixed and 1 failure is due to a compiler error and not considered harmful. That leaves function::sum_avg_portable math::octonion_test math::quaternion_test test::errors_handling_test to be fixed or to be explained. Note, all these tests fail for both CVS HEAD and RC_1_30_0. I've just installed 3.3.1 on Windows, and am getting those same four failure plus failures from: date_time/testmicrosec_time_clock (runtime failure) iterator/interoperable_fail (compile_fail test isn't failing) That seems like a reasonable number to fix or otherwise account for. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
En réponse à David Abrahams [EMAIL PROTECTED]: Martin Wille [EMAIL PROTECTED] writes: David Abrahams wrote: In that case, can I release 1.30.2? I don't like having the 1.30.1 debacle hanging over my head. There are new regressions on Linux (RC_1_30_0 branch): http://boost.sourceforge.net/regression-logs/cs-Linux-rc-1_30_0/developer_summary_page.html crc has regressions for gcc-3.1 and gcc-3.2.3 config, format and io have regressions for intel 7.1 According to your chart, the following libraries are all regressing: [...] numeric/interval [...] Nothing has been commited to the RC_1_30_0 branch for the interval library, so there should be no regression. In fact, the regression you speak about happens with gcc-3.4-cvs. Martin was careful not to mention these failures in his mail. Are these real regressions or just newly-tested compilers? Can the library authors/maintainers address these problems? Where is our maintenance wizard? Mainly newly-tested compilers (gcc-3.3.1 and gcc-3.4). You just have to focus on gcc-3.1, gcc-3.2.3 and intel-7.1 columns. Regards, Guillaume ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
On Fri, 8 Aug 2003, Martin Wille wrote: - function::sum_avg_portable Should be fixed now. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: For a lightly used toolset like intel-7.1 with STLPort, looks for all the world like a config problem seems like a good enough resolution to me. In that case, can I release 1.30.2? I don't like having the 1.30.1 debacle hanging over my head. Can it wait a day or two? As regression maintainers, we are interested in fixing this one. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
Beman Dawes wrote: Assuming I'm release manager for 1.31.0, I'm going to publish explicit release criteria for key platform/compiler pairs. Basically, the criteria will be 100% accounting for all failures on those platform/compiler pairs. While I totally support the failures markup goal, I would like to see _the_ release criteria to include no regressions from the previous release item as well, preferrably for all non-beta compilers that are currently under regression testing. Especially since now we have tools to ensure it. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
Martin Wille wrote: If there is enough time left then I'll run the tests for the 1.30.0 release and gcc-3.1.1. The chart for the RC_1_30_0 branch should look better then. Done. There are no regressions for gcc-3.3.1/Linux. Regards, m ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
David Abrahams wrote: Regarding http://tinyurl.com/jhtn: does this compiler ever need the typename keyword? If not, perhaps we ought to define BOOST_NO_DEDUCED_TYPENAME for all Borland versions Any particular failure that triggered your attention? Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
David Abrahams wrote: Matthias Troyer [EMAIL PROTECTED] writes: ... I would be interested in hearing about the plans for a Boost 1.31 release As far as I know the CVS is in very good health at the moment. The only major thing I know needs to be done is to complete the documentation for the new iterator adaptors. I'd like to get that over with soon, so it isn't hanging over our heads much longer. In order to avoid problems to be discovered too late for fixing them I'll list the tests that fail for many compilers/compiler versions on Linux: - filesystem::operations_test - function::sum_avg_portable - iterator::interoperable_fail (a compile_fail test that fails, probably not a real problem) - math::octonion_test math::quaternion_test - test::errors_handling_test I hope that lists helps. Regards, m ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
David Abrahams wrote: Many are simply not going to get better; they're due to compiler bugs which can't be worked around. Which is totally fine. If you provide us with the list of expected failures, these will be cleared. All of the *_fail tests that are failing should be cleared. Actually I don't know about bcc-5.6.4 since I don't have that compiler, but I expect the conditions are the same as for bcc-5.5.1. Will be done. As for the others, the failures you're reporting with intel-7.1 are very strange; my 7.1 compiler doesn't have these problems AFAIK. Hmm, looks like another configuration problem to me. We'll take a look at it. What does the meta- prefix mean? meta- is our prefix for non-boost toolsets. It's a strange standard to hold boost libraries to, passing on toolsets which are not checked into the Boost CVS. Can we do something about that? Well, sure, as long as we are in agreement about having differently named toolsets for different compiler versions/configurations, e.g. bcc-5.5.1 bcc-5.6.4 intel-7.1-vc60 intel-7.1-vc60-stlport etc. Do you have some special configuration of each of these compilers? Well, most of them are not really special. For instance, bcc-* ones were introduced for the only purpose of being able to test 5.5.1 and 5.5.4 compilers simultaneously. The complete list of differences is available here - http://www.meta-comm.com/engineering/resources/cs-win32_rc_1_30_0_metacomm/patches.html That's good to know. Is there a link on the main summary page? It's on our TODO list (the regressions on the branch and on the main trunk are being run on different machines, and these are slightly out of sync). Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
At 10:50 PM 8/10/2003, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: ... iterator/interoperable_fail (compile_fail test isn't failing) That is a compiler bug, which I guess ought to be reported again. Yes. It saves us work in the long run when compilers get fixed. Please do report it. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
Rene Rivera wrote: [2003-08-11] David Abrahams wrote: Aleksey Gurtovoy [EMAIL PROTECTED] writes: Well, sure, as long as we are in agreement about having differently named toolsets for different compiler versions/configurations, e.g. bcc-5.5.1 bcc-5.6.4 intel-7.1-vc60 intel-7.1-vc60-stlport It's OK with me. I'd rather that they have the same root as the base toolsets... borland-5.5.1 borland-5.6.4 intel-win32-7.1-vc60 intel-win32-7.1-vc60-stlport Makes for easier maintenance. OK, we'll go with these. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
On Mon, 11 Aug 2003, David Abrahams wrote: According to your chart, the following libraries are all regressing: function Are these real regressions or just newly-tested compilers? Can the library authors/maintainers address these problems? Where is our maintenance wizard? All of the failures for function are due to newly-tested compilers. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Boost 1.31 release?
At 08:45 AM 8/11/2003, Jeff Garland wrote: I've just installed 3.3.1 on Windows, and am getting those same four failure plus failures from: date_time/testmicrosec_time_clock (runtime failure) This is likely due to the posix API call to std::time not providing stable return values. That is, when I sample the time rapidly the second value is less than the previous value. So this is more of a platform / library issue than a compiler issue. This isn't a new problem with this particular configuration... OK, I've added a note to that effect. Consider the failure accounted for. Is there any point to report this to someone? Cygwin? --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
David Abrahams wrote: Misha and Aleksey -- I think we really need to distinguish those failures from real regressions in the chart somehow or we'll never be able to tell where we stand. Well, it was assumed that when adding a new compiler one should use re-run the regressions against the previous release and report the current status using _those_ expected results. Many tests might have worked on the new compiler by chance with the previous release. It isn't fair to demand that maintainers to fix bugs on compilers they haven't agreed to support. I am not sure how your remark is related to this particular sub-thread, but I agree, actually. On the other hand, some of the compilers which the library author(s) might be indifferent to are of some interest to the regression test maintaniners and some number of users. It would be unfair to _not_ to give them a chance to keep those supported by a small amount of cooperation on everyone's side. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
At 09:56 AM 8/9/2003, Matthias Troyer wrote: As far as I can see Jens Maurer has updated boost.random to his standards proposal, but not yet the documentation. I believe it would be important to have the random documentation be consistent with the sources, especially since the interface has changed significantly. I've added this to the 1.31.0 task list. See http://sourceforge.net/pm/task.php?group_project_id=30994group_id=7586func=browse Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
David Abrahams wrote: Aleksey Gurtovoy [EMAIL PROTECTED] writes: I worry a little about requiring library authors not to regress on compiler combinations they don't test with. Well, the regressions are run daily, so testing happens. Another question is whether library authors care about how their libraries perform on all the compilers the regressions are being run on. Obviously, some compilers/configurations are included in the regression testing because the ones who manage the latter are the ones who are most interested in those. Then, again, obviously, some compilers/ configurations are included in the regressions because they are very widely used. For every release, the interested parties include library authors, regression runners, the release manager, the maintenance wizard, and of course active users who are subscribed to either of the lists. Given the above setup, the implied interests of the participating groups, and their explicit and implicit responsibilities and gratitude towards each other, I think striving for no regressions goal I stated above would be both a reasonable and fair strategy which can be made to work. Some people are posting regressions for pre-release compilers. Should a library author should be expected to keep his library healthy on some weird/broken compiler just because it happened to work there by chance at one point? You skipped the part of my original posting which explicitly said: While I totally support the failures markup goal, I would like to see _the_ release criteria to include no regressions from the previous release item as well, preferrably for all non-beta compilers that are currently under regression testing. Especially since now we have tools to ensure it. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
At 07:37 AM 8/11/2003, David Abrahams wrote: Aleksey Gurtovoy [EMAIL PROTECTED] writes: Beman Dawes wrote: Assuming I'm release manager for 1.31.0, I'm going to publish explicit release criteria for key platform/compiler pairs. Basically, the criteria will be 100% accounting for all failures on those platform/compiler pairs. While I totally support the failures markup goal, I would like to see _the_ release criteria to include no regressions from the previous release item as well, preferrably for all non-beta compilers that are currently under regression testing. Especially since now we have tools to ensure it. I worry a little about requiring library authors not to regress on compiler combinations they don't test with. For example, who is going to address the one lexical_cast failure that's plaguing the 1.30.2 release? It's only on intel-7.1 with STLPort and looks for all the world like a config problem. It can be very time consuming to track down the exact reason for failures. Thus we should focus our 1.31.0 effort on a small number of widely used compilers which don't have a lot of problems. For a lightly used toolset like intel-7.1 with STLPort, looks for all the world like a config problem seems like a good enough resolution to me. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
Aleksey Gurtovoy wrote: Martin Wille wrote: The new reports are now checked into the main trunk and RC_1_30_0 branch. Martin, if you are interested in upgrading to these, you would need to re-generate the expected results file from the 1.30.0 tarball run - it has to contain more information to support the new status higlighting. I tried the new reports for the 1_30_0 branch.The results look broken now. Everything that used to be in red is yellow now. (yellow is ok for gcc-3.4-cvs, but the other fields should be red). Err, sorry, broken check-in! Fixed now. Could you please re-generate the expected results file, and try it again? Yes, now the colours look fine. In the meantime, some fixes have been applied to the RC_1_30_0 code. Now, there are only these regressions left for Linux in the RC_1_30_0 branch: crc_test for gcc 3.1 and gcc.3.2.3 format tests for intel 7.1 New results for cvs head will be available tomorrow. Regards, m ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
Aleksey Gurtovoy wrote: Aleksey Gurtovoy wrote: David Abrahams wrote: Misha and Aleksey -- I think we really need to distinguish those failures from real regressions in the chart somehow or we'll never be able to tell where we stand. Here - http://www.meta-comm.com/engineering/resources/cs-win32_metacomm/developer_summary_page.html Yellow cells indicate failures on the newly added tests/compilers. The updated report tools are not in the CVS yet, we will check them in after the first round of feedback. The new reports are now checked into the main trunk and RC_1_30_0 branch. Martin, if you are interested in upgrading to these, you would need to re-generate the expected results file from the 1.30.0 tarball run - it has to contain more information to support the new status higlighting. I tried the new reports for the 1_30_0 branch.The results look broken now. Everything that used to be in red is yellow now. (yellow is ok for gcc-3.4-cvs, but the other fields should be red). Regards, m ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
Beman Dawes wrote: At 05:12 AM 8/11/2003, Alisdair Meredith wrote: Aleksey Gurtovoy wrote: While I totally support the failures markup goal, I would like to see _the_ release criteria to include no regressions from the previous release item as well, preferrably for all non-beta compilers that are currently under regression testing. Especially since now we have tools to ensure it. OTOH, it might not always be achievable. For boost 1.31 we are having an interface breaking change to the iterator_adaptors, and not all compilers pass all tests with the new adaptors yet. While this may not be a problem for the iterators library (it is effectively new) it may have a knock-on effect on any other boost libraries implemented on top of it. The principle is a good one, but I be prepared to make a few allowances in the practice. I think a reasonable goal is that any regressions should be understood and discussed, rather than silent. Exactly my sentiments. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
Martin Wille wrote: The new reports are now checked into the main trunk and RC_1_30_0 branch. Martin, if you are interested in upgrading to these, you would need to re-generate the expected results file from the 1.30.0 tarball run - it has to contain more information to support the new status higlighting. I tried the new reports for the 1_30_0 branch.The results look broken now. Everything that used to be in red is yellow now. (yellow is ok for gcc-3.4-cvs, but the other fields should be red). Err, sorry, broken check-in! Fixed now. Could you please re-generate the expected results file, and try it again? Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Boost 1.31 release?
I've just installed 3.3.1 on Windows, and am getting those same four failure plus failures from: date_time/testmicrosec_time_clock (runtime failure) This is likely due to the posix API call to std::time not providing stable return values. That is, when I sample the time rapidly the second value is less than the previous value. So this is more of a platform / library issue than a compiler issue. This isn't a new problem with this particular configuration... Jeff ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Boost 1.31 release?
On Mon, 11 Aug 2003, David Abrahams wrote: [snip] Are these real regressions or just newly-tested compilers? Can the library authors/maintainers address these problems? Where is our maintenance wizard? He's back online after three weeks of no-internet-access-whatsoever; currently reading through a few hundred emails to see what's been happening during that time. Quite a bit, it would seem. Bjorn ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
Beman Dawes wrote: At 11:13 PM 8/10/2003, Aleksey Gurtovoy wrote: Beman Dawes wrote: Assuming I'm release manager for 1.31.0, I'm going to publish explicit release criteria for key platform/compiler pairs. Basically, the criteria will be 100% accounting for all failures on those platform/compiler pairs. While I totally support the failures markup goal, I would like to see _the_ release criteria to include no regressions from the previous release item as well, preferrably for all non-beta compilers that are currently under regression testing. Especially since now we have tools to ensure it. That sounds reasonable to me. Especially since now we have tools to ensure it. Damn. I forgot to bookmark the URL. Could you post it again please? Here's the page that links to all the reports we currently provide - http://www.meta-comm.com/engineering Please note that at the moment the main trunk report is not run against 1.30.0 results, but using the failures markup you provided us with - thus a greater number of red color there. Or better yet add something to boost-root/status/compiler_status.html linking to the permanent location. That in turn means deciding what of your experiment work is permanent and where it will live. Will happily do that, although it'll probably take some time to figure out the best way. We'll post the prototype for the discussion before actually checking it in. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
At 02:56 PM 8/11/2003, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: For a lightly used toolset like intel-7.1 with STLPort, looks for all the world like a config problem seems like a good enough resolution to me. In that case, can I release 1.30.2? Yes, as far as I'm concerned. I don't like having the 1.30.1 debacle hanging over my head. Understood. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
Martin Wille wrote: 6 tests fail for 3.2.3 and 6 tests fail for 3.3.1 Doh. 5 tests fail for 3.3.1. Sorry for the typo. Regards, m ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
[2003-08-11] David Abrahams wrote: Aleksey Gurtovoy [EMAIL PROTECTED] writes: Well, sure, as long as we are in agreement about having differently named toolsets for different compiler versions/configurations, e.g. bcc-5.5.1 bcc-5.6.4 intel-7.1-vc60 intel-7.1-vc60-stlport It's OK with me. I'd rather that they have the same root as the base toolsets... borland-5.5.1 borland-5.6.4 intel-win32-7.1-vc60 intel-win32-7.1-vc60-stlport Makes for easier maintenance. -- grafik - Don't Assume Anything -- rrivera (at) acm.org - grafik (at) redshift-software.com -- 102708583 (at) icq ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
At 01:39 PM 8/8/2003, Martin Wille wrote: In order to avoid problems to be discovered too late for fixing them I'll list the tests that fail for many compilers/compiler versions on Linux: - filesystem::operations_test Hum... That looks like a CVS problem. It looks like boost-root/libs/filesystem/src/operations_posix_windows.cpp has not been updated to 1.15. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
Beman Dawes wrote: At 07:37 AM 8/11/2003, David Abrahams wrote: Aleksey Gurtovoy [EMAIL PROTECTED] writes: Beman Dawes wrote: Assuming I'm release manager for 1.31.0, I'm going to publish explicit release criteria for key platform/compiler pairs. Basically, the criteria will be 100% accounting for all failures on those platform/compiler pairs. While I totally support the failures markup goal, I would like to see _the_ release criteria to include no regressions from the previous release item as well, preferrably for all non-beta compilers that are currently under regression testing. Especially since now we have tools to ensure it. I worry a little about requiring library authors not to regress on compiler combinations they don't test with. For example, who is going to address the one lexical_cast failure that's plaguing the 1.30.2 release? It's only on intel-7.1 with STLPort and looks for all the world like a config problem. It can be very time consuming to track down the exact reason for failures. Thus we should focus our 1.31.0 effort on a small number of widely used compilers which don't have a lot of problems. It doesn't have to be the release manager who investigates all the issues himself, though. There might be enough of the interested parties with motivation/resources to resolve most of these in a reasonable time frame if they a given a chance/managed properly. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
Alisdair Meredith wrote: Aleksey Gurtovoy wrote: While I totally support the failures markup goal, I would like to see _the_ release criteria to include no regressions from the previous release item as well, preferrably for all non-beta compilers that are currently under regression testing. Especially since now we have tools to ensure it. OTOH, it might not always be achievable. For boost 1.31 we are having an interface breaking change to the iterator_adaptors, and not all compilers pass all tests with the new adaptors yet. While this may not be a problem for the iterators library (it is effectively new) Yes. it may have a knock-on effect on any other boost libraries implemented on top of it. And any failures concerned with the interface change per se should be fixed before the release. It might happen that major changes in a library inadvertently cause _functionality regression_ on the particular compiler, but IMO inadvertently is a key word here. The principle is a good one, but I be prepared to make a few allowances in the practice. Sure, as long as it's an explicit decision. After all, those could be put in the release notes. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
David Abrahams wrote: Matthias Troyer [EMAIL PROTECTED] writes: Dear Boosters, Since some of the applications and libraries we plan on releasing soon rely on Boost features and bugfixes that are in the CVS but not in Boost 1.30.[012] I wonder what the plans are for the Boost 1.31.0 release? Since we would prefer to base our released software on a Boost release instead of a CVS snapshot I would be interested in hearing about the plans for a Boost 1.31 release As far as I know the CVS is in very good health at the moment. Uhmm, I really wouldn't say so! If you look at the main trunk report - http://www.meta-comm.com/engineering/resources/cvs_main_trunk/developer_summary_page.html, there are lots of regressions comparing to 1.30.0, and IMO we ought to fix all these before we branch for the release or anything. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
At 01:39 PM 8/8/2003, Martin Wille wrote: David Abrahams wrote: Matthias Troyer [EMAIL PROTECTED] writes: ... I would be interested in hearing about the plans for a Boost 1.31 release As far as I know the CVS is in very good health at the moment. The only major thing I know needs to be done is to complete the documentation for the new iterator adaptors. I'd like to get that over with soon, so it isn't hanging over our heads much longer. In order to avoid problems to be discovered too late for fixing them I'll list the tests that fail for many compilers/compiler versions on Linux: - filesystem::operations_test - function::sum_avg_portable - iterator::interoperable_fail (a compile_fail test that fails, probably not a real problem) - math::octonion_test math::quaternion_test - test::errors_handling_test I hope that lists helps. Assuming I'm release manager for 1.31.0, I'm going to publish explicit release criteria for key platform/compiler pairs. Basically, the release criteria will be 100% accounting for all failures on those platform/compiler pairs. I assume that Linux/GCC will be one of those platform/compiler pairs. I need input from Linux/GCC experts as to which version of GCC should be used for the release criteria. I see GCC 3.3.1 has just been released, and so will be switching the Windows/GCC tests to use that version. Unless anyone objects, it will be one of the Windows release criteria compilers. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
David Abrahams wrote: As far as I know the CVS is in very good health at the moment. Uhmm, I really wouldn't say so! If you look at the main trunk report - http://www.meta-comm.com/engineering/resources/cvs_main_trunk/developer_summary_page.html, there are lots of regressions comparing to 1.30.0, and IMO we ought to fix all these before we branch for the release or anything. I can't really tell what these represent. As usual, a red cell means a regression from the 1.30.0 tarball, a dark green one - an improvement. All of the new iterator library tests which weren't in 1.30.0 are showing up as regressions if they're failing. Yes, it's a known shortcoming - or a feature, depending of how you look at it. By default, new tests are expected to pass. Many are simply not going to get better; they're due to compiler bugs which can't be worked around. Which is totally fine. If you provide us with the list of expected failures, these will be cleared. As for the others, the failures you're reporting with intel-7.1 are very strange; my 7.1 compiler doesn't have these problems AFAIK. Hmm, looks like another configuration problem to me. We'll take a look at it. What does the meta- prefix mean? meta- is our prefix for non-boost toolsets. Do you have some special configuration of each of these compilers? Well, most of them are not really special. For instance, bcc-* ones were introduced for the only purpose of being able to test 5.5.1 and 5.5.4 compilers simultaneously. The complete list of differences is available here - http://www.meta-comm.com/engineering/resources/cs-win32_rc_1_30_0_metacomm/patches.html Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
