Subject: Re: [boost] [test] boost.test owner unresponsive to persistent problems for multiple years
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2015-01-22 01:29:24
On 21. jan. 2015 23:26, 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
>>>>> 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
> I always speak on behalf of myself.
> 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.
Good, this is clarifying. What puzzles me then is why you can not work
with Gennadiy more actively now as others seems to do, rather than
iterating over this "If I was given control - it would have been fixed
long time ago" argument.
>> 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
> Boost.Test is not leading mindshare.
> With an attitude that 5 years of waiting for simple fixes is
> acceptable, why would anyone be surprised?
I don't really get too worried about success of alternatives to
Boost.Test. I think it is wonderful that there are excellent
alternatives out there as long as they don't kill all competition and we
loose benefits of competition and alternatives again. So what we need
now is for Boost.Test to wake up and come out from hibernation.
>> 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
> 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.
There was, and is, all reasons in the world to poke the maintainer for
the state of things. I don't blame you for having used sharper tools too
stir up a reaction. But excessive use of sharp tools may just be too
much, and hurt forward progress. Please do not underestimate the force
and reach of your words.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk