Johannes Schindelin <johannes.schinde...@gmx.de> 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.