Boost regression notification (2006-09-22 [RC_1_34_0])
Boost Regression test failures Report time: 2006-09-22T12:06:02Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/is... 293 failures in 14 libraries filesystem (5) graph (7) io (1) iostreams (14) mpl (5) parameter (62) program_options (9) python (95) rational (5) serialization (16) spirit (49) test (2) utility (1) wave (22) |filesystem| convenience_test: msvc-8.0 fstream_test: msvc-8.0 mbcopy: sun-5.8 path_test: msvc-8.0 wide_test: sun-5.8 |graph| graphviz_test: intel-vc71-win-9.1 msvc-7.1 msvc-8.0 msvc-8.0 msvc-8.0 serialize: sun-5.8 vc-7_0 |io| ios_state_unit_test: gcc-4.1.0_linux_x86_64 |iostreams| bzip2_test: msvc-7.1 msvc-7.1 msvc-8.0 msvc-8.0 example_test: vc-6_5-stlport finite_state_filter_test: cw-9.4 gzip_test: msvc-7.1 msvc-7.1 msvc-8.0 msvc-8.0 zlib_test: msvc-7.1 msvc-7.1 msvc-8.0 msvc-8.0 |mpl| multiset: gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc gcc-4_0_3_tru64 sort: gcc-4_0_3_tru64 vector_c: sun-5.8 |parameter| basics: borland-5_6_4 borland-5_8_2 compose: borland-5_6_4 borland-5_8_2 deduced: borland-5_6_4 borland-5_8_2 deduced_dependent_predicate: borland-5_6_4 borland-5_8_2 vc-6_5 vc-6_5-stlport earwicker: borland-5_6_4 borland-5_8_2 efficiency: borland-5_6_4 borland-5_8_2 macros: borland-5_6_4 borland-5_8_2 maybe: borland-5_6_4 borland-5_8_2 vc-6_5 vc-6_5-stlport vc-7_0 mpl: borland-5_6_4 borland-5_8_2 normalized_argument_types: borland-5_6_4 borland-5_8_2 vc-6_5 vc-6_5-stlport vc-7_0 ntp: borland-5_6_4 borland-5_8_2 optional_deduced_sfinae: borland-5_6_4 borland-5_8_2 sun-5.8 vc-6_5 vc-6_5-stlport vc-7_0 preprocessor: borland-5_6_4 borland-5_8_2 preprocessor_deduced: borland-5_6_4 borland-5_8_2 sun-5.8 python-parameter-test: vc-6_5 vc-6_5-stlport vc-7_0 python_test: cw-9.4 darwin-4.0.1 gcc-4_0_3_tru64 hp_cxx-71_006_tru64 qcc-3.3.5_gpp sun-5.8 sfinae: borland-5_6_4 borland-5_8_2 vc-6_5-stlport singular: borland-5_6_4 borland-5_8_2 vc-6_5 vc-6_5-stlport vc-7_0 tutorial: borland-5_6_4 borland-5_8_2 unnamed: msvc-7.1 msvc-8.0 |program_options| cmdline_test_dll: cw-9.4 options_description_test_dll: cw-9.4 parsers_test_dll: cw-9.4 positional_options_test_dll: cw-9.4 unicode_test_dll: borland-5_8_2 cw-9.4 variable_map_test_dll: borland-5_8_2 cw-9.4 winmain_dll: cw-9.4 |python| andreas_beyer: darwin-4.0.1 hp_cxx-71_006_tru64 args: darwin-4.0.1 auto_ptr: darwin-4.0.1 back_reference: darwin-4.0.1 bases: darwin-4.0.1 gcc-4.1.1_sunos_i86pc hp_cxx-71_006_tru64 ben_scott1: darwin-4.0.1 hp_cxx-71_006_tru64 bienstman1: darwin-4.0.1 bienstman2: darwin-4.0.1 bienstman3: darwin-4.0.1 borrowed: darwin-4.0.1 callbacks: darwin-4.0.1 const_argument: darwin-4.0.1 hp_cxx-71_006_tru64 crossmod_exception: darwin-4.0.1 hp_cxx-71_006_tru64 crossmod_opaque: darwin-4.0.1 data_members: darwin-4.0.1 defaults: darwin-4.0.1 dict: darwin-4.0.1 docstring: darwin-4.0.1 enum: darwin-4.0.1 exception_translator: darwin-4.0.1 exec: darwin-4.0.1 gcc-4.1.1_sunos_i86pc hp_cxx-71_006_tru64 extract: darwin-4.0.1 implicit: darwin-4.0.1 injected: darwin-4.0.1 iterator: darwin-4.0.1 keywords: darwin-4.0.1 hp_cxx-71_006_tru64 list: darwin-4.0.1 long: darwin-4.0.1 minimal: darwin-4.0.1 multi_arg_constructor: darwin-4.0.1 nested: darwin-4.0.1 numpy: darwin-4.0.1 gcc-3.3.6 gcc-3.4.4 object: darwin-4.0.1 object_manager: darwin-4.0.1 opaque: cw-9.4 darwin-4.0.1 hp_cxx-71_006_tru64 intel-vc71-win-9.1 operators: darwin-4.0.1 pearu1: darwin-4.0.1 pickle1: darwin-4.0.1 pickle2: darwin-4.0.1 pickle3: darwin-4.0.1 pickle4: darwin-4.0.1 pointee: darwin-4.0.1 gcc-4.1.1_sunos_i86pc hp_cxx-71_006_tru64 pointer_type_id_test: darwin-4.0.1 gcc-4.1.1_sunos_i86pc hp_cxx-71_006_tru64 pointer_vector: darwin-4.0.1 polymorphism: darwin-4.0.1 polymorphism2: darwin-4.0.1 polymorphism2_auto_ptr: darwin-4.0.1 properties: darwin-4.0.1 hp_cxx-71_006_tru64 raw_ctor: darwin-4.0.1 return_arg: darwin-4.0.1 select_arg_to_python_test: darwin-4.0.1 select_from_python_test: darwin-4.0.1 gcc-4.1.1_sunos_i86pc select_holder: darwin-4.0.1 shared_ptr: darwin-4.0.1 slice: darwin-4.0.1 gcc-3.3.6 gcc-3.4.4 gcc-4.1.0_linux_x86_64 hp_cxx-71_006_tru64 staticmethod: darwin-4.0.1 stl_iterator: darwin-4.0.1 str: darwin-4.0.1 test_pointer_adoption: darwin-4.0.1 try: darwin-4.0.1 tuple: darwin-4.0.1 upcast: darwin-4.0.1 gcc-4.1.1_sunos_i86pc hp_cxx-71_006_tru64 vector_indexing_suite: darwin-4.0.1 virtual_functions: darwin-4.0.1 voidptr: cw-9.4 darwin-4.0.1 hp_cxx-71_006_tru64 intel-vc71-win-9.1 wrapper_held_type: darwin-4.0.1 |rational| rational_test: borland-5_6_4 sun-5.8 vc-6_5 vc-6_5-stlport vc-7_0 |serialization| test_class_info_load_text_warchive: vc-6_5 test_non_default_ctor2_text_archive: qcc-3.3.5_cpp test_non_default_ctor2_text_archive_dll: qcc-3.3.5_cpp test_non_default_ctor2_text_warchive: qcc-3.3.5_cpp test_non_default_ctor2_text_warchive_dll: qcc-3.3.5_cpp test_reset_object_address: vc-7_0 test_reset_object_address_dll: vc-7_0 test_simple_class_binary_archive_dll: vc-6_5 test_simple_class_text_archive_dll: vc-6_5 test_simple_class_text_warchive_dll: vc-6_5 test_simple_class_xml_archive_dll: vc-6_5 test_simple_class_xml_warchive_dll: vc-6_5 test_variant_xml_archive: borland-5_8_2 test_variant_xml_archive_dll: borland-5_8_2 test_variant_xml_warchive: borland-5_8_2 test_variant_xml_warchive_dll: borland-5_8_2 |spirit| action_tests: cw-9.4 darwin-4.0.1 gcc-3.3.6 gcc-3.4.4 gcc-3.4.5_linux_x86_64 gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc gcc-4_0_3_tru64 hp_cxx-71_006_tru64 intel-vc71-win-9.1 msvc-7.1 msvc-8.0 msvc-8.0 qcc-3.3.5_cpp qcc-3.3.5_gpp action_tests_debug: cw-9.4 darwin-4.0.1 gcc-3.3.6 gcc-3.4.4 gcc-3.4.5_linux_x86_64 gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc gcc-4_0_3_tru64 hp_cxx-71_006_tru64 intel-vc71-win-9.1 msvc-7.1 msvc-8.0 msvc-8.0 qcc-3.3.5_cpp qcc-3.3.5_gpp directives_tests: cw-9.4 gcc-3.4.5_linux_x86_64 gcc-4.1.0_linux_x86_64 directives_tests_debug: cw-9.4 gcc-3.4.5_linux_x86_64 gcc-4.1.0_linux_x86_64 mix_and_match_trees: sun-5.8 primitives_tests: cw-9.4 gcc-3.4.5_linux_x86_64 gcc-4.1.0_linux_x86_64 primitives_tests_debug: cw-9.4 gcc-3.4.5_linux_x86_64 gcc-4.1.0_linux_x86_64 scanner_tests: cw-9.4 gcc-3.4.5_linux_x86_64 gcc-4.1.0_linux_x86_64 scanner_tests_debug: cw-9.4 gcc-3.4.5_linux_x86_64 gcc-4.1.0_linux_x86_64 |test| parameterized_test_test: vc-6_5 vc-6_5-stlport |utility| operators_test: gcc-3.4.5_linux_x86_64 |wave| testwave: cw-9.4 darwin-4.0.1 gcc-3.4.4 gcc-4.1.1_sunos_i86pc gcc-4_0_3_tru64 intel-vc71-win-9.1 msvc-7.1 msvc-8.0 msvc-8.0 testwave_dll: darwin-4.0.1 gcc-3.3.6 gcc-3.4.4 gcc-4.1.1_sunos_i86pc gcc-4_0_3_tru64 hp_cxx-71_006_tru64 intel-vc71-win-9.1 msvc-7.1 msvc-8.0 msvc-8.0 qcc-3.3.5_cpp qcc-3.3.5_gpp sun-5.8
Douglas Gregor <dgregor@cs.indiana.edu> writes: | Boost Regression test failures | Report time: 2006-09-22T12:06:02Z | | This report lists all regression test failures on release platforms. | | Detailed report: | http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/is... | | 293 failures in 14 libraries This number seems to just be going up lately. Will a 1.34 release ever happen? And... there already seems to be enough new stuff in trunk for a new release... -- Lgb
larsbj@gullik.net (Lars Gullik Bjønnes) writes:
Douglas Gregor <dgregor@cs.indiana.edu> writes:
| Boost Regression test failures | Report time: 2006-09-22T12:06:02Z | | This report lists all regression test failures on release platforms. | | Detailed report: | http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/is... | | 293 failures in 14 libraries
This number seems to just be going up lately.
Really? I've been knocking it down hard, and making steady progress on _my_ problems, anyway. A reconfiguration of test machines at OSL caused the entire Boost.Python library to start failing on one of their machines yesterday, but the problem has been diagnosed. It's a momentary glitch, I assure you.
Will a 1.34 release ever happen?
Yes. You're welcome to pitch in by clearing inspection reports and/or regressions if you want to help move things along.
And... there already seems to be enough new stuff in trunk for a new release...
Yes; we will change repositories and release procedures after 1.34 in order to keep this from happening again. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes: | larsbj@gullik.net (Lars Gullik Bjønnes) writes: | | > Douglas Gregor <dgregor@cs.indiana.edu> writes: | > | > | Boost Regression test failures | > | Report time: 2006-09-22T12:06:02Z | > | | > | This report lists all regression test failures on release platforms. | > | | > | Detailed report: | > | http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/is... | > | | > | 293 failures in 14 libraries | > | > This number seems to just be going up lately. | | Really? I've been knocking it down hard, and making steady progress | on _my_ problems, anyway. A reconfiguration of test | machines at OSL caused the entire Boost.Python library to start | failing on one of their machines yesterday, but the problem has been | diagnosed. It's a momentary glitch, I assure you. It is not the momentary glitches that worry. Perhaps it is the "buisiness as usual" on the mailinglist and not the all-out focus on getting the 1.34 release out that worry me most. Note that this is the feeling I get when I read the mailing lists quite cursory, so it might very well not be accurate at all. This is a list of failures in regressions report 2006-08/09: 1. 271 failures in 23 libraries 2. 268 failures in 24 libraries 3. 268 failures in 24 libraries 4. 268 failures in 24 libraries 5. 268 failures in 24 libraries 6. 268 failures in 24 libraries 7. 268 failures in 24 libraries 8. 238 failures in 23 libraries 9. 239 failures in 23 libraries 10. 240 failures in 24 libraries 12. 204 failures in 24 libraries 14. 693 failures in 32 libraries (Ok, glitch. No need to worry.) 15. 692 failures in 32 libraries 16. 692 failures in 32 libraries 18. 692 failures in 32 libraries 19. 175 failures in 24 libraries 20. 171 failures in 21 libraries 31. 232 failures in 22 libraries (another small glitch?) Regressions reports 2006-09: 1. 158 failures in 19 libraries 2. 149 failures in 19 libraries 3. 150 failures in 20 libraries (steady decline, good.) 4. 150 failures in 20 libraries 5. 149 failures in 20 libraries 6. 149 failures in 19 libraries 7. 101 failures in 17 libraries (really getting somehwere now.) 8. 100 failures in 17 libraries 9. 106 failures in 18 libraries (... what? going up again?) 10. 107 failures in 18 libraries 11. 109 failures in 18 libraries 12. 161 failures in 17 libraries (Hmm...) 14. 88 failures in 17 libraries (Sudden drop? Also a glitch?) 15. 209 failures in 20 libraries (Massive increase?) 16. 278 failures in 24 libraries (...and another...?) 17. 288 failures in 19 libraries 18. 238 failures in 18 libraries 19. 220 failures in 19 libraries 22. 293 failures in 14 libraries (Glitch at OSL) | > Will a 1.34 release ever happen? | | Yes. You're welcome to pitch in by clearing inspection reports and/or | regressions if you want to help move things along. I inspection reports does not worry me much, and imho they are getting too much attention (seemingly) over the regression reports. We have at least upgraded our development software to use 1.34 from cvs, so that we can discovere problems therein before the actual release. And personally I try to have a report on platform(s) that concern me and that I might be able to help with. -- Lgb
larsbj@gullik.net (Lars Gullik Bjønnes) writes:
David Abrahams <dave@boost-consulting.com> writes:
| larsbj@gullik.net (Lars Gullik Bjønnes) writes: | | > Douglas Gregor <dgregor@cs.indiana.edu> writes: | > | > | Boost Regression test failures | > | Report time: 2006-09-22T12:06:02Z | > | | > | This report lists all regression test failures on release platforms. | > | | > | Detailed report: | > | http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/is... | > | | > | 293 failures in 14 libraries | > | > This number seems to just be going up lately. | | Really? I've been knocking it down hard, and making steady progress | on _my_ problems, anyway. A reconfiguration of test | machines at OSL caused the entire Boost.Python library to start | failing on one of their machines yesterday, but the problem has been | diagnosed. It's a momentary glitch, I assure you.
It is not the momentary glitches that worry. Perhaps it is the "buisiness as usual" on the mailinglist and not the all-out focus on getting the 1.34 release out that worry me most.
That's a worry, I agree. What can we do to fix that?
| Yes. You're welcome to pitch in by clearing inspection reports and/or | regressions if you want to help move things along.
I inspection reports does not worry me much, and imho they are getting too much attention (seemingly) over the regression reports.
They both have to get dealt with, but you're probably right. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes: | larsbj@gullik.net (Lars Gullik Bjønnes) writes: | | > David Abrahams <dave@boost-consulting.com> writes: | > | > | larsbj@gullik.net (Lars Gullik Bjønnes) writes: | > | | > | > Douglas Gregor <dgregor@cs.indiana.edu> writes: | > | > | > | > | Boost Regression test failures | > | > | Report time: 2006-09-22T12:06:02Z | > | > | | > | > | This report lists all regression test failures on release platforms. | > | > | | > | > | Detailed report: | > | > | http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/is... | > | > | | > | > | 293 failures in 14 libraries | > | > | > | > This number seems to just be going up lately. | > | | > | Really? I've been knocking it down hard, and making steady progress | > | on _my_ problems, anyway. A reconfiguration of test | > | machines at OSL caused the entire Boost.Python library to start | > | failing on one of their machines yesterday, but the problem has been | > | diagnosed. It's a momentary glitch, I assure you. | > | > It is not the momentary glitches that worry. Perhaps it is the | > "buisiness as usual" on the mailinglist and not the all-out focus on | > getting the 1.34 release out that worry me most. | | That's a worry, I agree. What can we do to fix that? I know that this has been discussed, but I still think that putting the cvs repo in a "regressions only" mode would have helped. (And wait with the release branch until trunk is in a fairly regression free state) btw. I'll try to do a regression run on my platform now (x86_64 gcc 4.1.1) and see if there are still issues there. -- Lgb
larsbj@gullik.net (Lars Gullik Bjønnes) writes:
| That's a worry, I agree. What can we do to fix that?
I know that this has been discussed, but I still think that putting the cvs repo in a "regressions only" mode would have helped.
I need to know what *will* help (not would have helped), or it's all academic. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes: | larsbj@gullik.net (Lars Gullik Bjønnes) writes: | | > | That's a worry, I agree. What can we do to fix that? | > | > I know that this has been discussed, but I still think that putting | > the cvs repo in a "regressions only" mode would have helped. | | I need to know what *will* help (not would have helped), or it's all | academic. Close trunk for non-regressions checkins now. -- Lgb
Lars Gullik Bj_nnes said: (by the date of 24 Sep 2006 13:03:23 +0200)
Close trunk for non-regressions checkins now.
That's the spirit, great decision! http://tinyurl.com/lawq3 spirit has failures on every platform ;-o -- Janek Kozicki |
Janek Kozicki wrote:
Close trunk for non-regressions checkins now.
That's the spirit, great decision!
spirit has failures on every platform ;-o
That was my fault... Should be finally fixed now. Regards Hartmut
participants (6)
-
David Abrahams -
Douglas Gregor -
Hartmut Kaiser -
Janek Kozicki -
larsbj＠gullik.net -
Markus Schöpflin