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

On Thu, Jun 4, 2020 at 11:20 AM Elijah Newren [off-list ref] wrote:

On Wed, Jun 3, 2020 at 2:01 PM Junio C Hamano [off-list ref] wrote:

Now, it's possible these regressions could just be a reflection of the
fact that I'm focusing more on fixing inconsistent behaviors

I agree with that. It's very difficult to implement big changes like
changing the rebase backend without any regression at all.

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.

It's possible to add more tests, but it's not possible to test
everything and it's hard to know it the tests we add are effective at
avoiding regressions. Not sure we can do much better.

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.

Great! At GitLab we are slowly moving toward something like that, but
not there yet.

(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).

That's a good idea.

Now to go back to Junio's question:

... 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?

Yeah, I agree that increasing the number of early adopters could be
the best way to avoid regressions report just after the release.

Maybe we could just ask people to test rc releases or 'master' in Git
Rev News? It might work better if someone wrote a small article about
what is coming in the next release before asking to test. Then there
is the issue of making it easier to build Git and to understand and
fix build issues. We could also perhaps coordinate Git Rev News
editions and Git releases, so that the editions are published for
example between rc-1 and rc-2  releases.

Best,
Christian.