Re: [boost] Another variant type (was: [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue mem

Subject: Re: [boost] Another variant type (was: [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue mem
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-04-02 21:16:54

On 2 Apr 2015 at 17:33, Eric Niebler wrote:

> On 4/2/2015 11:06 AM, Niall Douglas wrote:
> > These endless discussions about how best to implement Boost's future
> > wouldn't be happening if every top tier new C++ library was always
> > assumed de facto by its author to eventually be destined for Boost.
> > The fact that so many top tier authors, including so many formerly
> > with a big presence here, no longer bother with Boost I think speaks
> > volumes about what's gone wrong here with how library quality is
> > assessed here.
> 
> Speaking strictly for myself here: the reason I haven't pushed to get my
> recent open source contributions into Boost is not because I consider my
> code of higher quality. If anything it's quite the opposite. Getting a
> library into Boost is so daunting and time-consuming that -- at least
> for the work I'm doing these days -- I just don't have the time. It
> pains me to say that. I don't have the time to produce Boost-quality
> documentation and to exhaustively test everything. Concepts are coming.
> It's not hard to see that the STL will need a ground-up rewrite. I
> needed to get on the Concepts train, and it was going to pull out of the
> station with or without me. It would take half a year to make range-v3
> Boost-worthy. By that time, I'd have missed my chance to get ranges
> baked in from day 1.

I absolutely agree. I'm just out of six weeks of staying up till 5am 
each night after the family went to bed to get AFIO v1.3 out the 
door. That's because it had to be Boost peer review quality as it's 
in the review queue. I ended up dumping perhaps 200 hours in getting 
a feature complete and what I would have called "finished" library 
into a Boost peer review quality library. That's 200 hours I did not 
bill hourly to clients for, and as a consequence my earnings have 
taken a big hit for the past two months.

If I were still working at BlackBerry, I am highly unsure if 
regularly releasing a Boost library is compatible with not getting 
divorced and/or not fired.

> Maybe that speaks to Boost's review process, but it doesn't speak to the
> quality of Boost's code, which I consider very high.
> 
> I realize that doing an end-run around Boost to get ranges in the
> standard is deflating for everybody who has worked to make Boost what it
> is. That includes me.

And this is where the nub lies in where my vision of Boost 2.0 
differs from Robert's. I want to see an incrementing score 
automatically generated such that when you Eric throw caution to the 
wind and accidentally dump three days of work into your potential 
Boost library because something in it bugged you, you immediately see 
a jump in your library's rank. If Boost programmers are like any 
other type of human being, that immediate gratification has highly 
positive effects on you repeating that misallocation of your time 
sooner rather than later. Especially as most of the 200 hours 
invested in getting a library release Boost ready is drudge work - 
soak unit testing for 24h, writing yet more unit testing, spending 
three nights consecutively in the debugger tracking down some rare 
unrepeatable segfault, writing yet more tutorial toy use examples. 
That sort of thing. All stuff which needs to be rapidly rewarded 
psychologically, else you'll avoid it even more.

That tight feedback loop spurring people on psychologically to 
accidentally do better can't happen when human review is involved. 
Especially when people are waiting *three* *years* to get a review - 
though I am very glad Emil finally has a review manager as a result 
of this thread.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/