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

On 21. jan. 2015 23:26, Richard wrote:

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

=?windows-1252?Q?Bj=F8rn_Roald?= spake the secret code <54B0E109.8060307@4roald.org> thusly:

...

On 10. jan. 2015 02:06, Richard wrote:

...

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

Edward Diener spake the secret code 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.

Good, thanks.

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.

Very true.

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?

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

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. -- Bjørn