On Sat, Mar 18, 2023 at 1:26 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> At this point, I'm going to suggest that reviewers should be open to the
> idea of applying a submitted patch to some older Git commit in order to
> review it. If we have given feedback, then it's OK to put a patch as
> "waiting on author" and eventually boot it; but if we have not given
> feedback, and there is no reason to think that the merge conflicts some
> how make the patch fundamentally obsolete, then we should *not* set it
> Waiting on Author. After all, it is quite easy to "git checkout" a
> slightly older tree to get the patch to apply cleanly and review it
> there.
It seems plausible that improved tooling that makes it quick and easy
to test a given patch locally could improve things for everybody.
It's possible to do a git checkout to a slightly older tree today, of
course. But in practice it's harder than it really should be. It would
be very nice if there was an easy way to fetch from a git remote, and
then check out a branch with a given patch applied on top of the "last
known good git tip" commit. The tricky part would be systematically
tracking which precise master branch commit is the last known "good
commit" for a given CF entry. That seems doable to me.
I suspect that removing friction when it comes to testing a patch
locally (often just "kicking the tires" of a patch) could have an
outsized impact. If something is made extremely easy, and requires
little or no context to get going with, then people tend to do much
more of it. Even when they theoretically don't have a good reason to
do so. And even when they theoretically already had a good reason to
do so, before the improved tooling/workflow was in place.
--
Peter Geoghegan
