Re: [boost] [stacktrace] review (changing vote to NO)

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 
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.