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

From: "Kristoffer Haugsbakk" <[email-masked]>
Date: Mon, 29 Sep 2025 22:12:31 +0200

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.

-- 
Kristoffer