On Sat, Mar 18, 2023 at 1:26 PM Alvaro Herrera <alvhe...@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
