Re: [PATCH v3 0/4] Handle PuTTY (plink/tortoiseplink) even in GIT_SSH_COMMAND

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 1, 2017, 22:55 UTC
Message-ID: <xmqqr33hmshc.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <alpine.DEB.2.20.1702012311440.3496@virtualbox>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 6 quoted lines

>> Compared to the correctness issue, these are much harder to spot by
>> the submitter alone, who focused so intensely to get his code
>> "correct".  The review process is of greater value to spot these
>> issues.
>
> We will never agree on this.

That's too bad.

Show 9 quoted lines

> From my perspective, design, explanation and maintainability are a
> consequence of making it easy for reviewers to spot where the code is
> incorrect.
>
> And correctness is not covered by "the submitter tested this". Correctness
> includes all the corner cases, where the "many eyes make bugs shallow"
> really shines.
>
> I'd rather have reviewers find bugs than users.

I'd rather have submitters find bugs than reviewers.

> I will *never* be a fan of a review process that pushes correctness to a
> back seat (yes, it is much harder than spotting typos or lines longer than
> 80 columns per row, but the ultimate goal is to deliver value to the end
> user, not to make life easy for the maintainer).

Did I ever say correctness is pushed to a back seat?

I said that it is easier to spot correctness issues for you as a submitter than other kinds of issues without outside help (and implied that if you are a diligent contributor, you should aim for, and you should be able to achieve, a patch series where correctness issues do not need to be pointed out). But other higher level issues are harder for any submitter to spot (regardless of experience and competence of the submitter), because one gets so married to one's own code, design and worldview. And that is why "review is primarily to spot bugs" can never be a correct viewpoint.

A reviewee needs to be prepared to accept review comments on higher level issues, even more readily than comments on correctness issues, because it is too easy to be constrained by early decisions one has already made while preparing a patch series and become blind to bigger picture after staring one's own new code for number of hours. Higher level issues can be more easily spotted by reviewers, whose eyes are still fresh to the series.