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

> Le 29 sept. 2025 à 16:13, Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com> a écrit :
> 
> 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.