On 19/05/2016 20:57, Vicente J. Botet Escriba wrote:
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.
I'd agree with Andrey here. Per http://www.boost.org/community/reviews.html#Results a library can either be rejected or accepted, and it the latter case a list conditions for final acceptance can be specified. Sometimes, we do have a mini-review to check those conditions. However, it seems that "accepted subject to another full review" is a tad inconsistent. Do you think you could make your final review result explicitly list those and only those issues that must be addressed before the library is included, such that those issues can be reasonably rechecked without 10-day full review? Thanks, -- Vladimir Prus http://vladimirprus.com