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

From: Taylor Blau <me@ttaylorr.com>
Date: Sep 28, 2025, 02:21 UTC
Message-ID: <aNiblmQxtZyigbcu@nand.local>
In-Reply-To: <xmqqseg777k8.fsf@gitster.g>

On Sat, Sep 27, 2025 at 05:19:03PM -0700, Junio C Hamano wrote:

Show 16 quoted lines

> Taylor Blau <me@ttaylorr.com> writes:
>
> >> ... (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 a vague recollection that Google internally has their engineers
> > run a version of Git that is based on 'next'. But after spending a few
> > minutes searching through the list archives, I can't seem to find any
> > record of that.
>
> They do, but the frequency they update desktop installations is lower
> than the frequency I merge new topics to update the tip of 'next', so
> I suspect they alone would not be sufficient guinea pigs.

Good to know, and yeah, if Googlers aren't receiving 'next' updates as frequently as the maintainer is producing them, then I don't think that increases the risk of shortening the period for which topics cook on 'next' before graduating.

Show 17 quoted lines

> It would lead us into ugly awkwardness when we start clarifying what
> exactly "contributor" is in the new sentence, though.  If a person,
> whom none of us have ever heard of, sends their first message to
> this list saying "Ack", does that count?  If an active developer,
> who is known to be sloppier than others, sends an "Ack" to somebody
> else's patch that was posted 3 hours before (hence there wouldn't
> have sufficient time to think through the issues), how much should
> that "Ack" weigh?
>
> Perhaps rephrasing it to "those who have helped in polishing the
> patches with their reviews and discussing the issues with the patch
> author" to tighten the language a bit may help?
>
> I dunno, as that would still give the "ack right" to a random
> noisemaker who threw a drive-by "review" that did not add much value
> to the patches, if the original author responded "Thanks" out of
> courtesy.

Good point. Having a REVIEWERS file might help with that. Perhaps that file starts with just you on it, and then it can be expanded to form a network of trusted reviewers over time.

Building on the "how code review is done at GitHub" thing... GitHub has a concept of required reviewers for PRs based on what file(s) are modified as a part of the PR via its CODEOWNERS file. I share your feeling below that the project is not large enough to have individual areas have separate groups of reviewers, so perhaps just a single list is fine.

> True.  It was a strawman to invite other more realistic ideas (like
> your "positive ack required"), and was not necessarily designed to
> be workable ;-).

;-).

Thanks, Taylor