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

Subject: Re: [boost] [test] Looking for co-developer/maintainer
From: Darryl Green (darryl.green_at_[hidden])
Date: 2014-01-27 06:41:12

On 25 January 2014 08:52, Kim Barrett <kab.conundrums_at_[hidden]> wrote:

> On Jan 24, 2014, at 11:16 AM, Gennadiy Rozental <rogeeff_at_[hidden]> wrote:
> >
> > Alexander Lamaison <awl03 <at> doc.ic.ac.uk> 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
> using
> > them does not make them useless. There are some people (admetedly less
> 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 library 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 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".