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

From: Taylor Blau <me@ttaylorr.com>
Date: Sep 30, 2025, 20:02 UTC
Message-ID: <aNw3VY7npZvHDU7i@nand.local>
In-Reply-To: <aNsG5Jd_YLgrwarI@pks.im>

On Tue, Sep 30, 2025 at 12:23:32AM +0200, Patrick Steinhardt wrote:

Show 25 quoted lines

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

Show 5 quoted lines

> 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