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: Edward Diener (eldiener_at_[hidden])
Date: 2015-01-21 19:32:40

On 1/21/2015 5:26 PM, Richard wrote:
> [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.

My remark was a general one, and I am totally sympathetic to your 
viewpoint that Boost.Test has been badly neglected.

>
>> 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.

This is strictly my opinion but if you had forked Boost.Test, fixed the 
bugs, offered your updated documentation, and submitted it as a new 
library and as an improved version of Boost.Test I would have voted for 
its inclusion into Boost. Occasionally some library, which is an 
improvement over an already accepted Boost library, is likewise accepted 
as a separate Boost library ( signals/signals2 ) and I personally see 
nothing wrong with this idea.