Re: [boost] [test] boost.test owner unresponsive to persistent problems for multiple years

Subject: Re: [boost] [test] boost.test owner unresponsive to persistent problems for multiple years
From: Richard (legalize+jeeves_at_[hidden])
Date: 2015-01-21 17:26:56

[Please do not mail me a copy of your followup]

=?windows-1252?Q?Bj=F8rn_Roald?= <bjorn_at_[hidden]> spake the secret code
<54B0E109.8060307_at_[hidden]> thusly:

>On 10. jan. 2015 02:06, Richard wrote:
>> [Please do not mail me a copy of your followup]
>>
>> Edward Diener <eldiener_at_[hidden]> spake the secret code
>> <m8nv98$7nj$1_at_[hidden]> thusly:
>>
>>> On 1/8/2015 2:19 PM, Stephen Kelly wrote:
>>>> Paul A. Bristow wrote:
>>>>
>>>>> Things that effect *everyone* require consultation and some degree of
>>>>> consensus.
>>>>
>>>> The maintainer is always the decider. Consensus, even loose consensus,
>>>> doesn't affect Boost at all afaik. I realize you don't see it that way.
>>>
>>> I approve the fact that a primary maintainer is the decider. Someone has
>>> to be in charge, and surely that someone who did all the work of
>>> creating the library in the first place is the best candidate. If you
>>> disagree enough with the primary maintainer and feel your
>>> ideas/implementation are not being regarded and are better you can
>>> always create another library that reflects your own ideas and notify
>>> people on this mailing list about your own library.
>>
>> In this case, that's already been done.  It's called google test (gtest).
>
>I am confused, are you responding on behalf of Paul, or yourself 
>Richard?

I always speak on behalf of myself.

All I'm saying is that gtest is gaining acceptance because it supports
its community of users in a reasonable way.  Boost.Test is losing
ground and has been losing ground for 5+ years.

How often do you see anyone out there making a library that duplicates
the functionality of a boost library?  I haven't seen it happen very
often and at the moment, the only example I can think of is
Boost.Test.  There are MULTIPLE test frameworks out there that are
gaining users at the expense of Boost.Test.

The idea of "well, if you don't like what's happening, you should fork
and go your own route" is not interesting to me, because if I'm going
to abandon Boost.Test, I'll just use gtest.  There's no need to
reinvent my own test framework when there are other options out there.

>if your intentions are too take over Boost.Test ownership and make it 
>more or less into gtest, possibly breaking compatibility with existing 
>test code.

I offered to take over maintenance ownership of the library a while
back (9 months ago?  I don't remember exactly when) and the offer was
declined.  Had I been given that authority, then the docs and simple
fixes waiting 5 years to appear in a release would already have
shipped with 1.56 and we'd be moving on.  Instead, we're still waiting
for simple fixes to show up after 5 years of waiting.  We're told that
we'll have to keep waiting for simple fixes that were prepared 5 years
ago to show up.  With that sort of progress, I can't fault anyone for
using google test.

That is exactly the sort of attitude that results in the really great
book "Modern C++ Programming with Test-Driven Development" by Jeff
Langr <http://amzn.to/15bvh9C> relegating Boost.Test to a bare mention
in an appendix and using gtest throughout the book for all the
examples.

Boost.Test is not leading mindshare.

With an attitude that 5 years of waiting for simple fixes is
acceptable, why would anyone be surprised?

>Thanks for your effort by the way Richard!  I do however think you 
>should moderate your tone, hidden or literate, in some of your postings 
>given the maintainer seems to be responding now and have 
>co-maintainers/helpers.

The time for laughing with puppy dogs and picking daisies in a sunny
verdant field is long gone.

After waiting 5 years for the simple issue cited in this thread to be
resolved I'm told that I have to keep waiting and to be patient.  5
years is long enough for anyone to wait.  My patience has long since
been exhausted.
-- 
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
     The Computer Graphics Museum <http://computergraphicsmuseum.org>
         The Terminals Wiki <http://terminals.classiccmp.org>
  Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>