Rene Pijlman <rene@lab.applinet.nl> writes:
> I'm under the impression that JDBC receives more ad hoc patches
> from relative newcomers than the backend does. Therefore, I
> propose to follow a peer review procedure for applying patches
> to JDBC:
> 1) Every patch must be reviewable. It should be a clean diff and
> it must contain a clear description of the problem that's being
> solved, the reason for certain changes, JDBC compliance etc.
> 2) Every non-trivial patch should receive a positive
> recommendation from at least one person of a team of certified
> reviewers before it is applied. The review process (e.g. Q&A
> between reviewer and developer, approve/reject) occurs on the
> pgsql-jdbc list.
> This is already happening with a lot of patches, but I think it
> would be good to turn this practice into an official and
> documented procedure.
I would caution against getting overly bureaucratic. The Postgres
project has done quite nicely for the last five years with only informal
procedures, and I don't think we should change that dynamic.
Peer review is a good thing, no doubt about it, but don't get too
rigorous about it. Ultimately it's the committer's responsibility
to have confidence that the patch he applies is good; if he doesn't
feel competent to check it himself, he should call for more reviewers.
If he does feel sure about it, there's no need for procedural overhead.
Speaking of committers --- Barry, you've been nominated twice now.
Are you willing to accept that responsibility? I'll bring it up
with the core committee if you want to do it.
regards, tom lane
