Re: What's cooking in git.git (Jun 2020, #01; Wed, 3)

[Junio C Hamano <gitster@pobox.com>]

Elijah Newren <newren@gmail.com> writes:

> On Wed, Jun 3, 2020 at 2:01 PM Junio C Hamano <gitster@pobox.com> 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.