Subject: Re: [RFC] How to accellerate the patch flow (or should we?)

From: Patrick Steinhardt <[email-masked]>
Date: Tue, 30 Sep 2025 00:23:50 +0200

On Mon, Sep 29, 2025 at 10:12:31PM +0200, Kristoffer Haugsbakk wrote:
> On Sat, Sep 27, 2025, at 23:32, Taylor Blau wrote:
> > On Fri, Sep 26, 2025 at 03:24:04PM -0700, Junio C Hamano wrote:
> >>  4. While the above cycle is running, the maintainer may queue it in
> >>     'seen', for two purposes.  (1) not to lose sight and forget
> >>     about the change.  (2) to catch potential conflicts and overlaps
> >>     with other in-flight topics to keep their interaction manageable.
> >
> > Perhaps a third purpose is to let the maintainer (or those who use
> > and/or build off of 'seen' as their daily driver) detect any bugs in
> > that topic, or via interaction with other topics in 'seen'.
> >
> >> The time taken during 7. is pretty much fixed and unless we are
> >> willing to sacrifice the quality of the end result, cannot
> >> reasonably be shortened (note that this is based on the assumption
> >> that "find any remaining bugs while it is in 'next' before it hits
> >> 'master'" philosophy is working, but we have never run experiments
> >> to shorten this to say 3 days to see if we see more bugs on 'master'
> >> yet).
> >
> > I have mixed feelings about this. On the one hand, I am a little
> > uncomfortable with the idea of shortening the time in 'next' to fewer
> > than 7 days. I, too, have the feeling that having more time in 'next'
> > gives us a greater chance of spotting bugs in a topic that is otherwise
> > destined for 'master'.
> >
> > On the other hand, how many people are using 'next' as their daily
> > driver? Of those, how many are actively looking for bugs in the topics
> > that are in master..next. And of those, how many are actually triggering
> > unique code paths that would expose those bugs in the first place?
> 
> Theoretically all the projects that make heavy use of git(1) could run
> `next` (and `master`) as an alternative configuration of their
> integration tests.

At GitLab we do: we have nightly CI runs that execute our integration
tests with both `next` and `master`. This has already surfaced issues at
several points in time. We also have plans to roll out `next` to all of
our developers, but we haven't gotten around to this one yet.

Given the daily schedule of the CI runs it would be _okayish_ to reduce
the 7 days to something shorter. But realistically, not every pipeline
failure is noticed immediately, and sometimes we have different
priorities before we can dive into the pipeline failure.

The same is basically true for those companies that deploy to their devs
from `next`. There is a certain roundtrip time: the new version has to
be deployed, people have to start using it, and the bug reports have to
trickle back to the Git teams before they become actionable.

So I don't really feel like we can significantly reduce these 7 days
without losing some of the safety.

Patrick