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.
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/