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

[Patrick Steinhardt <ps@pks.im>]

On Sat, Sep 27, 2025 at 05:19:03PM -0700, Junio C Hamano wrote:
> Taylor Blau <me@ttaylorr.com> writes:
> > 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?

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