Josh Berkus wrote:
> As I don't think we can change this, I think the best answer is to tell people
> "Don't submit a big patch to PostgreSQL until you've done a few small
> patches first. You'll regret it".
>
When I last did a talk about getting started writing patches, I had a
few people ask me afterwards if I'd ever run into problems with having
patch submissions rejected. I said I hadn't. When asked what my secret
was, I told them my first serious submission modified exactly one line
of code[1]. And *that* I had to defend in regards to its performance
impact.[2]
Anyway, I think the intro message should be "Don't submit a big patch to
PostgreSQL until you've done a small patch and some patch review"
instead though. It's both a good way to learn what not to do, and it
helps with one of the patch acceptance bottlenecks.
> The problem is not the process itself, but that there is little
> documentation of that process, and that much of that documentation does
> not match the defacto process. Obviously, the onus is on me as much as
> anyone else to fix this.
>
I know the documentation around all this has improved a lot since then.
Unfortunately there's plenty of submissions done by people who never
read it. Sometimes it's because people didn't know about it; in others
I suspect it was seen but some hard parts ignored because it seemed like
too much work.
One of these days I'm going to write the "Formatting Curmudgeon Guide to
Patch Submission", to give people an idea just how much diff reading and
revision a patch should go through in order to keep common issues like
spurious whitespace diffs out of it. Submitters can either spent a
block of time sweating those details out themselves, or force the job
onto a reviewer/committer; they're always there. And every minute it's
sitting in someone else's hands who is doing that job instead of reading
the real code, the odds of the patch being kicked back go up.
[1] http://archives.postgresql.org/pgsql-patches/2007-03/msg00553.php
[2] http://archives.postgresql.org/pgsql-patches/2007-02/msg00222.php
--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us