Re: [boost] [test] Looking for co-developer/maintainer

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Darryl Green Sent: Monday, January 27, 2014 11:41 AM To: boost@lists.boost.org Subject: Re: [boost] [test] Looking for co-developer/maintainer

On 25 January 2014 08:52, Kim Barrett wrote:

...

On Jan 24, 2014, at 11:16 AM, Gennadiy Rozental wrote:

...

Alexander Lamaison writes:

...

I'm genuinely curious what aspects of Boost.Test, that Richard ommitted to document, you use. Maybe I'm far off the mark, but I doubt many people use the extra stuff that is basically an implementation detail.

These are not implementation details at all. The fact that you are not

...

them does not make them useless. There are some people (admetedly less

using then

...

those who are suing UTF) who need these to be documented.

I'm a long-time user of Boost.Test (> 8 years).

While I will certainly agree that the existing release documentation has some structural / organizational problems, that's an entirely different problem. [And one which no longer has much effect on me personally, since I've invested the time needed to know my way around in the current documentation.]

+1 to all that. Richards documentation efforts so far, are definitely a step in the right direction - a clearer and well structured lead in to using the library with the features explained as they are needed is what the

needed.

However docs on extending and using the lib beyond basic use cases (eg traversing the tests for producing custom result formats) are much needed. The docs on how the library works "internally" are needed to be able to use those extension points effectively.

FWIW, I suspect there is a large and silent (especially in this forum) user base of boost test

library that are for

the most part quite happy with the (if this thread is to believed) terribly unmaintained and broken boost.test in release. Hopefully a new and improved version can be released without breaking things - from where I sit its the rest of boost that changes wildly (a great thing - keep pushing that envelope) that is the challenge, not the stability of boost.test. My personal experience is limited to Windows x86, Windows CE ARM, Linux x86 and Linux ARM across a range of "vintage" and not so vintage compilers, but it "works for me".

Which is precisely why I believe we should not mess with the current release. It's the devil we know. Boost.Test has suffered mission creep. I believe that most would be well served by a simpler faster version. It could use the same MACRO names and would probably just drop in for many uses. It must have good documentation in a community maintainable form. The best way to avoid any disruption is to invite proposals for Boost.SimplerTest and let developers decide if and when to change. The two (or more) libraries can coexist happily for ever if necessary. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com