PostgreSQL's commitfest clog

"Preferably of similar complexity" is difficult in another way. At $DAYJOB I found an issue with Postgres and spent more than a week digging through code I'd never seen before, debugging it and eventually coming up with a solution, after some emails to the mailing list for clues. What is then "similar complexity"? Another patch that would take another week to dig into the code to understand what it does before you feel qualified to have an opinion?

For people who work on Postgres for a lot of time the cost is lower because they already know the code, and they already know many of the other core developers so know which bit they have to pay attention to.

At $DAYJOB code needs to be reviewed but there's a different dynamic in play. If you don't immediately understand something you simply talk to the person who wrote it. By asking questions you get an idea of (a) why was this solution chosen (b) what are the risks (c) what's the skill level so I know which kind of bugs I need to watch for. Also get a feeling of the urgency. A patch that has been in the queue for a year might be useless, or the writer has had it running in production that whole time and is confident it works. You can do this via email but, well, for complex patches that doesn't cut it.

Not sure if there's any easy solution, but I can imagine that for complex/controversial patches that a quick chat between the writer and a reviewer can help make a lot more progress than a commitfest manager sending emails. And I have no doubt that in-person conferences in the past helped immensely here.