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

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