[boost] Re: [1.33.0] Let's start preparations...

From: Misha Bergal (mbergal_at_[hidden])
Date: 2005-03-07 19:29:37

Martin Wille <mw8329_at_[hidden]> writes:

> David Abrahams wrote:
>> "Victor A. Wagner Jr." <vawjr_at_[hidden]> writes:
>> 
[...]

> I'll make a start, I hope others will contribute to the list.
> Issues and causes unordered (please, excuse any duplicates):

>From my side, I would like to comment on some of the raised issues
(this is not a rebuttal, most of the comments are about how the
problems got already resoved or can be resolved with "a little help
from our friends" :-) )

> - the code-change to result-rendering process takes too long

We are working on result-rendering process part. We recognize that
this has been a big bottleneck in the past and hopefully have
significantly improved it.

> - resource limitations at Sourceforge (e.g. the number of files there)

My problem with SF is that do not have much of control over the
environment there.

> - between releases the testing system isn't as well maintained as
>   during the release preparations.

Well, that's because in 1.32.0 timeframe a lot of effort went in the
releasing the release and creating the testing tools to ensure the
adequate quality of it, and it's been done by the same group of
people, who obviously need time to catch up with other things they
have.

> - library maintainers don't have access to the testing systems; this
>   results in longer test-fix cycles.

I investigated this a little bit: the current licensing for commercial
compilers doesn't permit to "access to the testing systems" by people
other than the licensee (not so with free compilers). If somebody with
more influence would make some kind of arrangement with a compiler
vendors, we for one could try to give people reasonable free access to
our test environment.

> - changes which will cause heavy load at the testing sites never get
>   announced in advance. This is a problem when testing resources have
>   to be shared with the normal workload (like in my case).

Can be alleviated by splitting testing vertically (by toolsets)

> - becoming a new contributor for testing resources is too difficult.

http://www.meta-comm.com/engineering/regression_setup/instructions.html
(Of course this needs to be easily accessible from main boost site)

> - post-release displaying of test results apparently takes too much
>   effort. Otherwise, it would have been done.

http://www.meta-comm.com/engineering/boost-regression/1_32_0/developer/summary_release.html
(Of course this needs to be more easily accessible from main boost site)

> - test post processing has to work on output from different
>   compilers. Naturally, that output is formatted differently.

Testing needs a better support from Boost.Build. Till that is
implemented we will depend on parsing the bjam output.

> - test post processing makes use of very recent XSLT features.

It is such an _enormous_ (trust me) pain to do without them. And it
would take quite a significant effort to manage w/o XSLT.

> - XSLT processing takes long (merging all the components that are
>   input to the result rendering takes ~1 hour just for the tests I
>   run)

Hopefully, not anymore. We merge all results in less than 30 minutes
now.

> I'm sure testers and library developers are able to add a lot more  to
> the list.

Thanks for constructive feedback.

-- 
Misha Bergal
MetaCommunications Engineering