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

[Elijah Newren <newren@gmail.com>]

On Thu, Jun 4, 2020 at 7:49 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> 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.

Thanks, I'm glad you're not worried about that.

2.26 drained me pretty bad, enough that I was somewhat apprehensive of
2.27 being released.  Then two quick reports after 2.27 was released
was quickly filling me with dread and had me considering how I could
change it.  Maybe I was just in an overly worried and drained mindset
when your email happened to arrive.

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

True, though I thought jrnieder's reports from Google's internal
testing were pretty cool; they caught some important bugs even if they
didn't catch everything.  The more of us doing stuff like that, the
better off we'll be, even if it's not as good as getting on a distro's
testing track.

Another consideration we could make is just scheduling .1 releases
automatically, and not limiting them to security fixes but instead
considering the same kinds of things that would be allowed around the
time of -rc1 or -rc2.  I still want to push to make the quality of .0
releases as high as we can, but given that human nature seems to lean
towards avoiding things until they are labelled as official, and since
we benefit from that wider feedback, maybe we adjust slightly to take
advantage of natural behavior and do .1 releases?  Anyway, just a
thought.