Le 19/05/2016 à 20:40, Vladimir Prus a écrit :
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?
Seen the reactions that I'm seen in this thread, I start to think that maybe I could be wrong with my decision. Before reconsidering it I would like to know how this is different of what happened with Boost.Fiber? The review was accepted conditionally twice. It seems to me that the list of conditions for the first conditional acceptance couldn't be checked without a 10-day full review period. What this is different compared with the Fit review? That I have not reported the list of issues to consider in this ML? That I have requested a full-review instead of a mini-review? If these are the cases, we could forget that I have taken my decision and I'll give it once I have the report. I could say that a mini-review is needed even if I believe that we need a full review, but this will not be honest from my part. I believe that we will need this 10-day review period if no more to review the revised Fit library. This is why I'm talking of the need of a full review. I don't consider to take time to review a library a bad thing as the first goal is for me to improve the library in all its aspects. If the Boost community considers that in these cases we should reject the library we should do the same in all the cases. Best, Vicente P.S. I have nothing against the Boost.Fiber library.