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

Taylor Blau [off-list ref] writes:

quoted

diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 86ca7f6a78a..789febefff8 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches

@@ -506,7 +506,10 @@ After the list reached a consensus that it is a good idea to apply the
 patch, re-send it with "To:" set to the maintainer{current-maintainer}
 and "cc:" the list{git-ml} for inclusion.  This is especially relevant
 when the maintainer did not heavily participate in the discussion and
-instead left the review to trusted others.
+instead left the review to trusted others.  Patch series must receive
+a positive "ack" from at least one contributor other than the primary
+patch series author in order to begin integrating it, subject to the
+maintainer's discretion.

 Do not forget to add trailers such as `Acked-by:`, `Reviewed-by:` and
 `Tested-by:` lines as necessary to credit people who helped your
--- >8 ---

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.

Despite the potential awkwardness I have to wonder whether this would
even help us with the goal to speed up the overall process. To me it
rather feels like there's another step now that a patch series has to go
through, so my naive expectation is that it will rather slow the process
down even more.

Am I missing something?

quoted

I am not sure the idea of adding more maintainers is a good one or not.
Since I am not sure exactly what you are envisioning here, I think there
are a couple of cases:

 - There is a quorum of maintainers, who are all collectively
   responsible for building 'jch', 'seen', 'next', and 'master'. Any two
   of them are required to agree to move a topic down in order to do so,
   without needing the other maintainer to weigh in.

 - There are sub-system maintainers who are responsible for their own
   trees, and who send pull requests to the primary maintainer to
   integrate their trees back into the primary maintainer's.

Git is not large enough to benefit from the latter arrangement.
What I had in mind was the former one.

True. The other problem I see is that it might also skew the rate of
patches towards subsystems that have more active contribtors (or rather
subsystem maintainers). Other subsystems that don't have the luxury
would then potentially be disfavored.

I guess this is especially an issue as the most active subsystems tend
to be the ones maintained by hosting providers like GitLab and GitHub.
Drive-by contributions on the other hand tend to be more cluttered
around different parts of Git, and here it's unlikely that we have
enough people to serve as subsystem maintainers.

Patrick