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

[Taylor Blau <me@ttaylorr.com>]

On Tue, Sep 30, 2025 at 12:23:32AM +0200, Patrick Steinhardt wrote:
> > 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?

The idea is that it would make things possibly quicker, but never
slower. Since the maintainer is also part of the "trusted ack-ers", the
only process change would be that the maintainer could choose to avoid
reading a series closely if it has already received an ack.

(As an aside, in the pseudo-patch I wrote above, the maintainer could
choose to bypass the process entirely, since it would continue to be at
their discretion. Perhaps that's just a semantics thing, since by
merging the series the maintainer is implicitly providing their own
"ack", without actually saying so.)

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

Yeah... to be clear, the "subsystem maintainers" idea was really just me
wondering aloud which of the two possible interpretations of what Junio
said above would make the most sense to me.

Thanks,
Taylor