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

From: Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com>
Date: Sep 29, 2025, 20:04 UTC
Message-ID: <87792693-58d9-4047-beae-38aa4c59ed41@app.fastmail.com>
In-Reply-To: <xmqqldm0am4b.fsf@gitster.g>

On Sat, Sep 27, 2025, at 00:24, Junio C Hamano wrote:

Show 17 quoted lines

> A typical lifecycle of a patch series sent to the list ought to be
> as follows:
>
>[snip]
>  7. If 7 calendar days passes since the topic was merged to 'next'
>     (or any incremental fixes are also added and merged to 'next')
>     without any further finding of more problems, the topic gets
>     merged to 'master'.  We often call this 'graduating'.
>
>[snip]
> 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).

Maybe pure documentation changes could cook for less than seven days. Not for the benefit of graduating to `master` faster but for the benefits that less integration time brings:

- Less integration overhead since things are less likely to touch the
  same code (docs) at the same time
- Less likely that you have to base new changes on pending series
  - Integration overhead that affects both the contributor and the
    maintainer
- Potential second order effects like not being afraid of splitting up a
  lengthy series into an uncontroversial preamble of pure fixes since
  the combined series won’t have such a long potential lifespan

Given a documentation series that either fixes something or subjectively (by consensus) improves something, what’s the risk of cooking for slightly less than seven days? You might introduce rendering regressions, which is not on the same order of badness that a software bug is. And as for the subjectively improved documentation: people who disagree on a subjective basis with a topic in `next` are already considered (?) a bit late to the party.

And you also might miss out on feedback from people who run `Documentation/doc-diff origin/master origin/next` when they are bored.[1] But again it doesn’t seem like a big risk or downside.

You still keep the same standard of review.  But save integration time.

🔗 1: https://lore.kernel.org/git/df251b0c-c593-41ed-903e-8fb1c323b874@app.fastmail.com/

-- 
Kristoffer Haugsbakk