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

Subject: Re: [boost] [test] Looking for co-developer/maintainer
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2014-01-28 11:46:29

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Darryl Green
> Sent: Monday, January 27, 2014 11:41 AM
> To: boost_at_[hidden]
> Subject: Re: [boost] [test] Looking for co-developer/maintainer
> 
> 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".

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
[phone]  07714330204
pbristow_at_[hidden]