At the risk of going off-topic again, I'll reply once.
On Sun, Dec 25, 2016 at 10:59 PM, Vladimir Batov
On 2016-12-26 03:32, Artyom Beilis wrote:
I really like the idea to have such a library in Boost.
Then IMO you should be at least voting conditional "yes".
Acknowledging the need for a particular functionality is not the same as accepting a particular implementation.
But I don't feel it is mature enough, especially the backends in their current state - and finally the backends are actually the most critical and hardest stuff to implement _correctly_
I am not disputing that at all. To say that the lib is in the perfect shape would be a stretch. That said, IMO expecting the author to do everything right, to address all imaginable use-cases and to provide extensive documentation that would satisfy everyone is an impossible task and, therefore, IMO it should not be the expectation during a review. I can't help feeling that quite often reviewers expect everything on a silver plate with all Ts crossed and everything. And then they want more. I do not believe that's a constructive attitude. IMO it puts an immense pressure and burden on the author without giving anything in return... even an incentive to come back. The "door" is simply shut with a message "go away; you might try knocking again and going through that same humiliation again with no promises at all".
I think you misunderstand the point of a review. If you read the review policy[1], you will notice that the main point of a review is to evaluate the library, identify its strong and weak spots. By turning a blind eye on a design flaw of a presented library you're doing a disservice to the library author and the library users. Instead, by giving constructive feedback (positive and negative), especially if supported by real world experience, you help the library improvement. In fact, this (the feedback) is the most valuable reward for the author from the review. And let me say, there's nothing humiliating in having a library rejected during a review.
Would not that be wiser to give the author an incentive to address the discussed issues, to accept the lib conditionally and to see the lib evolving, improving, finished as part of Boost? Surely, it won't give the users "everything". However, it'll give the users working "something" and will provide the author with a considerably better feedback and the desire to address that.
There are things that can be fixed post-review. Usually this includes minor and technical stuff, like adding support for particular compilers, fixing tests and docs. Sometimes that includes more complex stuff, but that may warrant conditional acceptance. There are other things that cannot be fixed easily and would probably require changing library design. Those changes often affect library API and usage patterns, which warrants the need of a new review of the reworked library. In those cases it's better to reject the library so that the new, improved version is presented later. Note that missing functionality, unless considered crucial for the library domain, is typically not considered a reason for rejection. In fact, I'd say, it's usually preferable that the library does less things but it does them well. New features can be added at a later stage to the already accepted library, and if the library is designed properly, these features would fit nicely. Consider also that whenever a library is accepted into Boost, the matter of backward compatibility appears. If the accepted library is somehow seriously flawed, that flaw may be difficult and painful to fix in the future. [1]: http://www.boost.org/community/reviews.html