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

Hi,

On Wed, Jun 3, 2020 at 2:01 PM Junio C Hamano [off-list ref] 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...

A disproportionate number of regressions that we've had in recent
releases have traced back to me.  2 of the 3 regressions from 2.27 do.
In the 2.26 release, we had a whole pile of regressions with rebase
due to the change in the default backend, which came from me.  And,
we've also had a bunch of "fun" with dir.c in _every_ _single_
_release_ (to the best of my memory anyway) since I got my foot caught
in that unrelenting trap[1], including 1 of the 3 reported regressions
in this latest release.  The regression reports after releases have
been weighing on me too; I was thinking about it a fair bit last week
as well as this week.

[1] https://kernel.googlesource.com/pub/scm/git/git/+/8d92fb292706fd8d13cfe55353b2ec9345153a3e


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.  But it's also quite
possible that I'm going about these cleanups wrong or at least
suboptimally.  I'm open for suggestions of what I should change, or
even experiments to try.

Recent attempts I've made to make things better: (1) I have in the
past month or so gotten a company internal distribution of git
started, with a growing number of users.  This distribution uses
pre-release versions of git, mostly off master so far though I'm
considering moving to 'next' for it.  (2) I pushed hard during 2.27
for the dir.c changes to either merge early in that cycle or wait
until early in the 2.28 cycle -- hoping that an early merge would give
more time for testing.  (This was an attempt to learn from the 2.26
rebase issues, since that merged late in the 2.26 cycle).

Any other ideas I should try?


Thanks,
Elijah