From: "Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail•com>
To: "Junio C Hamano" <gitster@pobox•com>, git@vger•kernel.org
Subject: Re: [RFC] How to accellerate the patch flow (or should we?)
Date: Mon, 29 Sep 2025 22:04:49 +0200 [thread overview]
Message-ID: <87792693-58d9-4047-beae-38aa4c59ed41@app.fastmail.com> (raw)
In-Reply-To: <xmqqldm0am4b.fsf@gitster.g>
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/
--
Kristoffer Haugsbakk
next prev parent reply other threads:[~2025-09-29 20:05 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-26 22:24 [RFC] How to accellerate the patch flow (or should we?) Junio C Hamano
2025-09-27 21:32 ` Taylor Blau
2025-09-28 0:19 ` Junio C Hamano
2025-09-28 2:21 ` Taylor Blau
2025-09-29 22:23 ` Patrick Steinhardt
2025-09-29 22:46 ` Junio C Hamano
2025-09-29 23:25 ` Patrick Steinhardt
2025-10-01 20:00 ` Junio C Hamano
2025-09-30 20:02 ` Taylor Blau
2025-09-30 20:28 ` Junio C Hamano
2025-09-29 20:12 ` Kristoffer Haugsbakk
2025-09-29 21:19 ` Ben Knoble
2025-09-29 22:23 ` Patrick Steinhardt
2025-09-29 22:23 ` Patrick Steinhardt
2025-09-30 20:04 ` Taylor Blau
2025-09-29 20:04 ` Kristoffer Haugsbakk [this message]
2025-09-29 22:12 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87792693-58d9-4047-beae-38aa4c59ed41@app.fastmail.com \
--to=kristofferhaugsbakk@fastmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox