git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com>
Cc: Taylor Blau <me@ttaylorr.com>, Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org
Subject: Re: [RFC] How to accellerate the patch flow (or should we?)
Date: Tue, 30 Sep 2025 00:23:50 +0200	[thread overview]
Message-ID: <aNsG9kmkfoToSmAD@pks.im> (raw)
In-Reply-To: <b583b17e-96a5-4f22-8cc4-acbd3dfec82b@app.fastmail.com>

On Mon, Sep 29, 2025 at 10:12:31PM +0200, Kristoffer Haugsbakk wrote:
> 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.

At GitLab we do: we have nightly CI runs that execute our integration
tests with both `next` and `master`. This has already surfaced issues at
several points in time. We also have plans to roll out `next` to all of
our developers, but we haven't gotten around to this one yet.

Given the daily schedule of the CI runs it would be _okayish_ to reduce
the 7 days to something shorter. But realistically, not every pipeline
failure is noticed immediately, and sometimes we have different
priorities before we can dive into the pipeline failure.

The same is basically true for those companies that deploy to their devs
from `next`. There is a certain roundtrip time: the new version has to
be deployed, people have to start using it, and the bug reports have to
trickle back to the Git teams before they become actionable.

So I don't really feel like we can significantly reduce these 7 days
without losing some of the safety.

Patrick

  parent reply	other threads:[~2025-09-29 22:23 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 [this message]
2025-09-29 22:23   ` Patrick Steinhardt
2025-09-30 20:04     ` Taylor Blau
2025-09-29 20:04 ` Kristoffer Haugsbakk
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=aNsG9kmkfoToSmAD@pks.im \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=kristofferhaugsbakk@fastmail.com \
    --cc=me@ttaylorr.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).