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

Taylor Blau [off-list ref] writes:

quoted

quoted

... (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