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

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/ (local)

-- 
Kristoffer Haugsbakk