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

Subject: Re: [boost] [stacktrace] review (changing vote to NO)
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2016-12-25 18:41:59

At the risk of going off-topic again, I'll reply once.

On Sun, Dec 25, 2016 at 10:59 PM, Vladimir Batov
<Vladimir.Batov_at_[hidden]> wrote:
> 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