Boost logo

Boost :

Subject: Re: [boost] [Boost-users] [afio] Formal review of Boost.AFIO
From: Roland Bock (rbock_at_[hidden])
Date: 2015-08-27 01:40:47


On 2015-08-27 04:36, Niall Douglas wrote:
> On 26 Aug 2015 at 5:31, Glen Fernandes wrote:
>
>>> [Paul] Correct - and more - "that we wish and
>>> trust Niall to get it right - eventually."
>> That did not sound like a strong "Accept" to me. It sounded
>> more like "Not reject" and "Please resubmit for review [after
>> getting it right, eventually]."
> The negative review responses so far have fallen into these
> categories:
>
> 1. Not all the APIs it uses are documented (because they are in other
> libraries). I will not look at this library until that is fixed.
>
> 2. Not all the APIs it uses are documented (because they are in other
> libraries). It therefore should be rejected.
>
> 3. The documentation has severe issues and needs a very great deal of
> additional work before it could be considered Boost-ready.
>
> 4. I think the fundamental design is flawed for these reasons X, Y
> and Z.
>
>
> Categories 1 and 2 are utterly useless to me. I appreciate the
> motives and where they are coming from, but let me be clear in
> return: if I bring AFIO back in twelve months time after lots more
> work, and those same people then say the design is fundamentally
> flawed for reasons X, Y and Z and should be rejected, I am going to
> be very upset with them indeed. I think anyone would understand where
> I would be coming from in that response.
So basically you are saying that anyone who votes against your library
for reasons 1 or 2 has no right to vote against it ever again, and you
will go to virtual war if they do?

My review will fall in categories 1, 2 and 3 (plus some additional
ones). And because I do not have unlimited time on my hand, I simply
cannot invest the time to find fundamental flaws. Doing that would
require me to basically rectify the issues at least on my machine and
then do the actual review. That is impossible.

I am willing to attribute this mail of yours to the high amount of
stress you feel, but please(!!) stop trying to put pressure on people
who intend to write a negative review.

>
> Category 3 has been an eye opener to put it mildly. I don't
> personally think severely flawed documentation is a reason to
> outright reject though. I do think that insufficient documentation is
> a reason to reject, but nobody can claim AFIO isn't well documented,
Again, stop pressurizing, please! I do claim that.

How do you expect to get a reasonable review if you basically state as a
fact that bad reviews on certain aspects are invalid by definition?

>
> it's just badly documented in a highly inaccessible structure with
> all the wrong information in the wrong places. That said, I think I
> have the fundamentals right e.g. race guarantees documented per API.
> There is a good base in there, I just hadn't realised where people
> get mentally stuck until now.
>
> Category 4 has been the most valuable, and that is exactly Thomas
> Heller's review. I personally believe AFIO's API design is the least
> worst possible given all the competing factors and pressures, else
> I'd present something better. However equally I may have chosen
> something wrong or misestimated the effect of some factor or
> pressure. Having to explain myself is immensely valuable - indeed
> right now it's 3.30am and I'm here typing this because I can't sleep
> thinking about how to explain my API design choices. Terrible on work
> life balance, hopefully great on a better API design if one is
> possible.
I feel you. And pretty much everybody here, to, I guess. But these
constant hints on how hard it was and continues to be and how every
additional hour hurts immensely? Please let go of that. This is adding
pressure for the reviewers, too. Because if you worked that hard for
such a long time under those circumstances, you have to be on the brink.
Any negative review has to be devastating.

I cannot remember a single review in which the author of the library
under review constantly tried to influence reviewers in the way you do.
For me personally, that means that I cannot be impartial, which is
actually going to be the first item in my review (I finished writing it
yesterday, btw, before reading this, I just wanted to check it again
after a few hours of sleep).

Sending the actual review will not happen until after a few more hours,
since I am already late for work for writing this mail, but I had to get
that off my chest.

Regards,

Roland


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk