Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
>> I prefer to cook it in 'next' sufficiently long to ensure that we hear
>> feedbacks from non-Windows users if there is any unexpected breakage.
>
> FWIW I am using the same patches not only on Windows but also in my Linux
> VM.
Thanks for a datapoint, but when I said "non-Windows users", I was
not referring you as "the" Windows user. I am expecting that you
would hear from Windows users who got exposure to your series by its
inclusion in Git for Windows. They are the ones that I had in mind
as "Windows users"---and not hearing breakage reported by them would
be a good sign.
The primary reason why we want to cook a new topic in 'next' is to
expose it to people with different workflows using it on different
things, and that is especially more important for a change that
affects features that are flexible and can be used in different
ways---the set of options and commands used by the original author
of the series are often different from other people's.
Any change, when it hits 'next', is expected to be sufficiently
tested by the original author [*1*], but that is only true in the
context of the original author's daily use. Both reviews and
author's tests are not sufficient to find bugs [*2*].
Topics that touch parts of the system that are more important to
users' daily Git life deserve extra time to find any unexpected
breakage in them. Windows users are participating in that test by
inclusion of the topic in the released version of Git for Windows.
I want to see the the test for the rest of the world done by early
adopters who run 'next' (as 'pu' is too scary for daily use).
[Footnote]
*1* And me, as topics geting ready to be in 'next' are first merged
to my private edition branch that is slightly ahead of 'next' to
be used in my everyday use, but just like the original author is
merely one user, I am also merely one user with a specific set
of workflows that is different from others'.
*2* Bug finding is not the primary purpose of the review in the
first place. It is to find design mistakes both at the external
and internal level, and bug finding "here you have off-by-one"
is merely a side effect. End user tests may expose the former
(e.g. the design based on a wrong assumption may not accomodate
certain workflow the original author and the reviewers failed to
consider while writing and reviewing), but no amount of test
will uncover the latter (e.g. internal API that is misdesigned
will make future enhancement unnecessarily harder).
I think it was one of the achievements of the review cycle of
this particular series that we got rid of the _entrust() thing,
for example. That had no visible external effect that would
have been caught by cooking on 'next' or releasing it to the
public, but was the kind of thing the code review was expected
to find and fix.