Subject: Re: [boost] Boost.Fit review Mars 3-20 result
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2016-05-19 13:57:13
Le 19/05/2016 Ã 03:04, Rob Stewart a Ã©crit :
> On May 18, 2016 2:18:16 PM EDT, "Vicente J. Botet Escriba" <vicente.botet_at_[hidden]> wrote:
>> Le 18/05/2016 Ã 10:29, Rob Stewart a Ã©crit :
>>> On May 18, 2016 12:52:06 AM EDT, Paul Fultz II <pfultz2_at_[hidden]>
>>>>> On May 17, 2016, at 11:29 PM, Robert Ramey <ramey_at_[hidden]> wrote:
>>>>> On 4/3/16 7:36 AM, Vicente J. Botet Escriba wrote:
>>>>>> The review of the proposed Boost.Fit library ended on Mars 20,
>>>>>> The verdict is:
>>>>>> Conditional acceptance (a new review is needed)
>>>>> Given the text I snipped, I don't see how one could characterize
>>>> review result as "Conditionally Accepted"
>>> Vicente will clarify his intent, but his post was somewhat ambiguous.
>> Robert, Rob, you are right that I could have rejected the library but
>> I've preferred to accept it subject to a new review.
> That still seems confusing. If it needs a new, full review, in what way was it accepted? I presume you mean to suggest that you think it's close to acceptable, and you want to encourage Paul to finish the effort, but can't you couch a rejection in those terms?
> IOW, I understand you to be saying, "While the library will be a powerful and useful tool, it is not yet ready for Boost to accept. I very much want Paul to make the changes that have been suggested, and which he had accepted, and to resubmit his library in the near future. Nevertheless, I must reject the library in its present form."
> Does that not convey your intent well, including encouraging Paul to finish the task, without being contradictory like your formulation?
Not exactly. As Giovanni has explained, a conditional acceptance means
something different than rejecting the library. We have identified
during the review a lot of points Paul is already taking care of. Most
of them concerns the documentation, some the design, and not too much
the implementation. The issues that must be fixed are most of them
already reported in github. I have not identified any issue that
couldn't be managed. What is missing is a report to the fixes that are
expected before a review. I don't use here explicitly a mini-review
because I want to let it clear that the whole library would be under
review and I will hope that we will have some deep reviews, not only for
the documentation but also the implementation and the tests.
My decision has already been taken and I don't see any reason to change it.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk