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

[Taylor Blau <me@ttaylorr.com>]

On Sat, Sep 27, 2025 at 05:19:03PM -0700, Junio C Hamano wrote:
> 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.

> 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