HP-UX_ia64_aCC and Boost 1.35
HP-UX_ia64_aCC is all green on the trunk except Interprocess library is marked as not supported. Assuming that the results on the release branch are as good as on the trunk (which is something we don't know at this point), would you be willing to consider adding HP-UX/aCC to the list of release platforms for 1.35, under the condition that Interprocess library does not have to be supported in 1.35 on this platform? To assess what the situation with 1.35 is, can I do a test run against release branch and, if so, what's the process? Just pass "--tag=branches/release" to run.py? Thanks, Boris
Boris Gubenko wrote:
HP-UX_ia64_aCC is all green on the trunk except Interprocess library is marked as not supported.
Nice!
Assuming that the results on the release branch are as good as on the trunk (which is something we don't know at this point),
We really want the release branch to be as good as the trunk before the release goes out.
would you be willing to consider adding HP-UX/aCC to the list of release platforms for 1.35, under the condition that Interprocess library does not have to be supported in 1.35 on this platform?
Yes. As long as Interprocess is marked up as not supported, that isn't a problem.
To assess what the situation with 1.35 is, can I do a test run against release branch
Yes, but I'd prefer you test daily rather than just run one test cycle.
and, if so, what's the process? Just pass "--tag=branches/release" to run.py?
Yes. Thanks, --Beman
Beman Dawes wrote:
Boris Gubenko wrote:
would you be willing to consider adding HP-UX/aCC to the list of release platforms for 1.35, under the condition that Interprocess library does not have to be supported in 1.35 on this platform?
Yes. As long as Interprocess is marked up as not supported, that isn't a problem.
Thanks!
Yes, but I'd prefer you test daily rather than just run one test cycle.
I can do full testing in a loop. A full test run takes ~8 hours and the results will be updated up to 3 times a day. Or I can do an incremental testing in a loop and frequency of the updates will depend on changes on the release branch, but, almost certainly, it will be more than 3 times a day. Which way is preferable? Thanks again, Boris
Boris Gubenko wrote:
Beman Dawes wrote:
would you be willing to consider adding HP-UX/aCC to the list of release platforms for 1.35, under the condition that Interprocess library does not have to be supported in 1.35 on this platform? Yes. As long as Interprocess is marked up as not supported, that isn't a
Boris Gubenko wrote: problem.
Thanks!
Yes, but I'd prefer you test daily rather than just run one test cycle.
I can do full testing in a loop. A full test run takes ~8 hours and the results will be updated up to 3 times a day. Or I can do an incremental testing in a loop and frequency of the updates will depend on changes on the release branch, but, almost certainly, it will be more than 3 times a day. Which way is preferable?
What I'm doing for Windows tests is a full test run once a day, and then incremental runs the rest of the time. Since the full run is done at night, that lightens the loads during the day when the machine is busier with other work. --Beman
Beman Dawes wrote:
What I'm doing for Windows tests is a full test run once a day, and then incremental runs the rest of the time. Since the full run is done at night, that lightens the loads during the day when the machine is busier with other work.
I'll implement a similar process when machines become available after the power outage, hopefully, later today (they are on the West Coast). Thanks, Boris
Boris Gubenko schrieb:
HP-UX_ia64_aCC is all green on the trunk except Interprocess library is marked as not supported.
[...] There is an acc test failure in the dynamic bitset library (affecting all 64 bit platforms, AFAICT), which only doesn't show up because it's marked as 'has been failing in the last release'. To make matters worse, this failure wasn't even present in the last release, so the markup is plain wrong. (It's probably from the version before, or something like that.) I think this highlights a problem in the way we're doing the markup for the known failures. If one test fails and is marked up accordingly for the release, there is no procedure that once this failure is fixed, the markup is removed. Nearly every platform currently tested has one ore more libraries showing dark green boxes, meaning that there is a test which unexpectedly passes. Before the release we should clear the markup for all these tests, otherwise the regression reports don't accurately tell whether there are regressions or not. If others agree that this is useful, I will take care of the markup for Tru64/CXX. Markus
on Sat Dec 01 2007, Markus Schöpflin <markus.schoepflin-AT-web.de> wrote:
Boris Gubenko schrieb:
HP-UX_ia64_aCC is all green on the trunk except Interprocess library is marked as not supported.
[...]
There is an acc test failure in the dynamic bitset library (affecting all 64 bit platforms, AFAICT), which only doesn't show up because it's marked as 'has been failing in the last release'.
To make matters worse, this failure wasn't even present in the last release, so the markup is plain wrong. (It's probably from the version before, or something like that.)
I think this highlights a problem in the way we're doing the markup for the known failures. If one test fails and is marked up accordingly for the release, there is no procedure that once this failure is fixed, the markup is removed.
I've been concerned about that for a long time. In my view, every bit of markup should have an attribute that says to which Boost major release it applies, and when testing for a new release, markup for older major releases should be ignored. So for example, you might see <test name="dyn_bitset_unit_tests1"> <mark-failure boost_version="1.34"> <toolset name="msvc-6.5_stlport4"/> <note author="Gennaro Prota" refid="37" /> </mark-failure> </test> By "major" I mean the difference between 1.34.x and 1.35.x, so developers would not have to update markup just for bugfix releases. Note also that I think the markup is going to have to be broken up into separate files by library pretty soon, but that is a different topic. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams schrieb:
on Sat Dec 01 2007, Markus Schöpflin <markus.schoepflin-AT-web.de> wrote:
Boris Gubenko schrieb:
HP-UX_ia64_aCC is all green on the trunk except Interprocess library is marked as not supported. [...]
There is an acc test failure in the dynamic bitset library (affecting all 64 bit platforms, AFAICT), which only doesn't show up because it's marked as 'has been failing in the last release'.
To make matters worse, this failure wasn't even present in the last release, so the markup is plain wrong. (It's probably from the version before, or something like that.)
I think this highlights a problem in the way we're doing the markup for the known failures. If one test fails and is marked up accordingly for the release, there is no procedure that once this failure is fixed, the markup is removed.
I've been concerned about that for a long time.
In my view, every bit of markup should have an attribute that says to which Boost major release it applies, and when testing for a new release, markup for older major releases should be ignored.
So for example, you might see
<test name="dyn_bitset_unit_tests1"> <mark-failure boost_version="1.34"> <toolset name="msvc-6.5_stlport4"/> <note author="Gennaro Prota" refid="37" /> </mark-failure> </test>
By "major" I mean the difference between 1.34.x and 1.35.x, so developers would not have to update markup just for bugfix releases.
Just removing the expected failures markup after every major release would have the same effect, wouldn't it? [...]
David Abrahams wrote:
on Sat Dec 01 2007, Markus Schöpflin <markus.schoepflin-AT-web.de> wrote:
Boris Gubenko schrieb:
HP-UX_ia64_aCC is all green on the trunk except Interprocess library is marked as not supported. [...]
There is an acc test failure in the dynamic bitset library (affecting all 64 bit platforms, AFAICT), which only doesn't show up because it's marked as 'has been failing in the last release'.
To make matters worse, this failure wasn't even present in the last release, so the markup is plain wrong. (It's probably from the version before, or something like that.)
I think this highlights a problem in the way we're doing the markup for the known failures. If one test fails and is marked up accordingly for the release, there is no procedure that once this failure is fixed, the markup is removed.
I've been concerned about that for a long time.
I've got similar concerns. My thought is to get 1.35.0 out of the way, then review testing issues before starting on the next release. That would probably be a good time to retire process_jam_log, for example, and switch to bitten as our main test harness if it is ready. --Beman
Markus Schoepflin wrote:
There is an acc test failure in the dynamic bitset library (affecting all 64 bit platforms, AFAICT), which only doesn't show up because it's marked as 'has been failing in the last release'.
Thanks for spotting it, Markus. I'll check if there are other failures on HP-UX/aCC marked as 'has been failing in the last release' which were not present in 1.34.1. As for dyn_bitset_unit_tests3 failure, I think I understand what's going on. It looks like a regression in boost/dynamic_bitset/dynamic_bitset.hpp introduced in 1.35, but even in 1.34.1, it seems to me that the code in to_ulong() is relying on undefined behaviour. I'll post separate message later today or tomorrow. On a different topic: there was a power outage in the lab Friday night and the machines I'm using for Boost testing will be unavailable until Monday. Thanks again, Boris ----- Original Message ----- From: "Markus Schöpflin" <markus.schoepflin@web.de> To: <boost@lists.boost.org> Sent: Saturday, December 01, 2007 10:11 AM Subject: Re: [boost] HP-UX_ia64_aCC and Boost 1.35
Boris Gubenko schrieb:
HP-UX_ia64_aCC is all green on the trunk except Interprocess library is marked as not supported.
[...]
There is an acc test failure in the dynamic bitset library (affecting all 64 bit platforms, AFAICT), which only doesn't show up because it's marked as 'has been failing in the last release'.
To make matters worse, this failure wasn't even present in the last release, so the markup is plain wrong. (It's probably from the version before, or something like that.)
I think this highlights a problem in the way we're doing the markup for the known failures. If one test fails and is marked up accordingly for the release, there is no procedure that once this failure is fixed, the markup is removed.
Nearly every platform currently tested has one ore more libraries showing dark green boxes, meaning that there is a test which unexpectedly passes. Before the release we should clear the markup for all these tests, otherwise the regression reports don't accurately tell whether there are regressions or not.
If others agree that this is useful, I will take care of the markup for Tru64/CXX.
Markus
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (4)
-
Beman Dawes -
Boris Gubenko -
David Abrahams -
Markus Schöpflin