On 2016-12-26 10:41, Andrey Semashev wrote:
... Acknowledging the need for a particular functionality is not the same as accepting a particular implementation.
Put bluntly users do not care about implementation. They care about functionality provided. I advocate giving the lib a "foot in the door". That and far better feedback from the users will be a strong incentive for the author to keep working and improving the lib. You seem to prefer all-or-nothing approach. I believe it's unrealistic and bad. You might disagree.
... 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 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.
Well, I suspect it might be quite hard to "misunderstand the point of a review"... It's not the rocket science after all. I honestly do not feel like arguing what the review policy means/says or was meant to mean/say and if everyone follows it to the letter.
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.
Well, I do not get scolded often these days. So, it is quite "refreshing" to learn that I am "turning a blind eye on a design" and "doing a disservice". I thought I was merely expressing my humble opinion... but probably I got it all wrong. As for the feedback, then I do not see voting something useful "no" to be much of a feedback. Indeed, the author does get initial feedback during a review. However, not all of that feedback is constructive. Some valid, some subjective, some capricious. After it's voted out the feedback is no more. Real valuable feedback will come when the lib is in Boost. People'll start using the lib (I would) in their real projects asking for this and that.
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? ... There are things that can be fixed post-review. ... 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.
Yes, all that sounds wonderful... on paper. In real life as a user I'll take what's available first. Then, if that is improved in the next version, I'll take it gladly. If design changes and gives me more or fixes something, I'll accept that. I do not remember Spirit transitioning from V1 to not backward-compatible V2 being re-reviewed. I can be wrong though. Everything evolves. Software more so. People adjust and move on. Please do not present it as the end of world.
In those cases it's better to reject the library so that the new, improved version is presented later.
Again, wonderful.. in theory. The reality IMO is different because 1) "improving" is better with real user feedback that you deny to the author by voting "no"; 2) "later" might never come as the review process is quite exhausting/draining; not everyone wants to experience it again; you might say "too bad for him"; I'll say it's bad for the user as well as they end up with your good intentions and no library; 3) "later" might be too late as by that time the user'll have something else in place.
... 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.
"difficult", "painful", "backward compatibility"... Come on. I am sure you've been in the industry for a while, have "survived" many upgrades/updates, etc. We all know it's not an issue. We update, adjust, move on.