Elijah Newren <newren@xxxxxxxxx> writes: > On Wed, Jun 3, 2020 at 2:01 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Seeing a handful of regression reports [*] immediately after a >> feature release is made gives me a mixed feeling: people are eager >> enough to help by reporting issues they encounter, but there are not >> enough people who are eager enough to help by testing the tip of >> 'master' before the release. Are there things we can do to help >> them become early adopters so that they do not have to scramble >> after the release? > > That's very diplomatically worded, but perhaps let me peel back that > deflection layer a bit and be more direct... Sorry, but you are reading too much into it. I am not worried about individual bugs; bugs happen and that is an inevitable part of development. I have enough confidence in our developers to feel that we can promptly fix a regression once an issue is raised and clarified sufficiently to be actionable. > Now, it's possible these regressions could just be a reflection of the > fact that I'm focusing more on fixing inconsistent behaviors rather > than adding new features, which is a type of work where it's much > harder to avoid fallout and reported issues. Yes, and as I said already, bugs happen and they tend to happen to those who touch the trickiest part of the existing code---it is inevitable. It is OK to be initially buggy as long as we can fix breakages promptly. I am however worried about how the issues often are not raised until a regression hits a tagged version. As a piece of software gets used more and more widely, it would be used in more and more different ways, and some of these ways may not be covered by developers' minds; by definition, some regressions are noticed only after a new version hits end users' hands. Basing in-house releases a Git developer has control over on 'master' or 'next' would reach audiences that the Git developer has access to, and as long as the in-house users use Git sufficiently differently from the Git developer (is that a realistic expectation, though?), we'd gain more coverage before a tagged release happens that way. Basing the version placed in a distro's 'testing' track on 'master' or 'next' may give us even wider exposure but it would be much harder to arrange, I am afraid. People from time to time suggest to merge trickier topics early in the cycle, and in principle I do agree that it may not be a bad idea, but given that we do not have enough folks on 'master', I am not so sure how much that would actially help. Thanks.
