Subject: Re: [boost] [stacktrace] review (changing vote to NO)
From: Vladimir Batov (Vladimir.Batov_at_[hidden])
Date: 2016-12-25 19:58:28
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
>> ... 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, 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.
> 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
> 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,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk