Rene Rivera wrote:
David Abrahams wrote:
Rene Rivera <grafik.list@redshift-software.com> writes:
It means that Martin is the only tester that is also posting the results to the boost.org/regression-results location. Everyone else is posting the only to the metacomm aggregator. Although when I'm actively running tests, near release time, I also post them to both places :-)
Okay, we have to fix that. This is just confusing.
I really thought we had already decided that there was no reason to post two different result formats. Is there any reason to keep the non-metacomm format up there?
We did agree to only have the metacomm results.
If we did, then why do we have 1 manual redirection to apply and 2 automatic redirections to see the results in the format we agreed on? (plus another link to click to see the summary instead of a page showing basically only a menu.) But I'm not sure all of
us feel that the metacomm results are giving accurate and responsive results. For one the processing delays seem rather long.
Yes, that's the main reason why I still provide the old format, too. Additionally, the metacomm postprocessing failed several times and the developers didn't have any uptodate test results. I'm still under the impression the XML based postprocessing procedure is a bit fragile.
I'm planning on working on the Boost buildbot next week, after a bit more work on getting my server ready. Hopefully the direct feedback that buildbot gives can help us streamline testing.
One thing we could do immediately is to not use the regression-logs location as the testing link. And instead point directly to the metacomm location. So for those who still care about the old style results they can remember to go to the regression-logs location. (Or anything else equivalent to deprecating the regression-logs location)
This is a good idea. Regards, m