Subject: Re: [boost] This AFIO review - a modest proposal
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-08-23 14:31:25
On 23 Aug 2015 at 9:55, Robert Ramey wrote:
> Reading the other posts I see trouble ahead. There is a strong current
> that suggests that the library is not ready to be reviewed.
Well, on that point:
1. AFIO has been in the review queue since 2013.
2. I am fairly confident you can write reliable, performant file
system applications with AFIO right now. It certainly has seen plenty
3. All the "heavy development" people refer to are, for the most
part, me going off and implementing feedback from people such as
yourself by wrapping the essentially unchanged core engine with "ease
of use" convenience APIs. I think you'll agree it looks a very
different library now than when you first reviewed it last year right
Robert? That's me responding to your feedback that you thought the
old API was unintuitive.
However the internal engine last saw much change a good six months
ago, and that was to add race free filesystem which wasn't anything
fundamental. People are blowing way out of proportion how much
serious change has been made to AFIO recently. The core engine has
been stable since 2013/2014. How much more stable does a Boost
library need to be before being considered production ready?
4. I think there is a BIG difference between "is it ready to be
reviewed?" and "is it ready to enter Boost?". I think it's an
emphatic yes to the first question: here is a well tested, stable
Boost library with high quality documentation and high quality
testing which has already undergone multiple rounds of feedback and
review, most of which has been fed back into changes and reforms to
the user facing library API.
In the end, you have got to ask "when is enough enough?" before it's
Is a well designed API, high quality documentation, high quality
testing and a core implementation stable for over six months no
longer sufficient for a library to enter Boost? All the new APIs are
thin wrappers over the old APIs, all of which are mostly unchanged
since 2013. The core implementation is essentially the same as end of
GSoC 2013. And as I mentioned, I only added the new APIs wrapping the
old APIs due to feedback from yourself and others.
If there are severe design flaws in AFIO, then it absolutely should
be rejected. But thanks to those multiple rounds of feedback, I think
most of the rusty nails have been hammered down by now. In which
case, what showstoppers remain between AFIO as presented and
Is acceptance of AFIO into Boost going to be judged on technical
reasons, or politics, or "I don't understand the point of this
> And there are strong concerns that you've rolled up too much in to one
I think this is entirely a valid concern, and I would absolutely
accept acceptance conditions listing what needs to be dropped.
> There is also some antipathy regarding they way you've gone about this
> and used the list so there is less inclination than there might
> otherwise be to cut you some slack. All this raises the bar to
> acceptance higher than it might otherwise be - which is already quite high.
As soon as I challenged the authority of certain people with an
alternative vision I was going to be heckled and hasseled every step
of the way onwards, both publicly and behind my back. That much
became very evident very early on, and for the record I wish it
weren't so, but you play the hand you're dealt and in every case it
has been someone who attacked me first even if that wasn't publicly
known, and I responded because nobody else was going to and unlike
other internet communities, there is not a strong central leadership
here so you are on your own to fight Darwinian style on every little
thing, so you get all this conflict and bitterness and unpleasantness
resulting. Which is a shame: it's wasted energy better spent on
writing code. But I also don't like being bullied, I *particularly*
don't like other people being bullied, and there was a lot of
bullying here back in 2012-2013 (much of which I think was
unintentional and just a product of then Boost culture). That happens
far less frequently now, and I would like to hope some of that less
adversarial more supportive culture is due to my efforts and
responses, even if it made me enemies along the way.
I prefer a quiet harmonious life. My life away from dealing with
Boost politics is extremely quiet and harmonious, I think I remember
telling you some of how boring I am in the Aspen bar at C++ Now.
> I propose that:
> a) this review be postponed.
I'll abide by whatever the review manager decides.
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk