Patch Submission Guidelines

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Patch Submission Guidelines
Date: 2006-02-14 17:20:55
Message-ID: 1139937655.1258.1004.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Many patch submitters discover that they fall foul of various "you
should have done"s at a late stage of the patch review process.
These include the usual:
- major feature change not discussed on -hackers or elsewhere first
- patch in wrong format
- performance patch, yet no performance test results to prove benefit
- no accompanying doc patch
- won't work on various ports (and it needs to)
etc..

In contrast, the documentation and translation process is extremely well
documented; this may be by design.

I would like to suggest that we increase substantially the FAQ entries
relating to patch submission. By we, I actually mean please could the
committers sit down and agree some clarified written guidelines?

There is nothing wrong right now with the level of quality of patches
that get accepted, so I do not wish to discuss lowering or increasing
the quality bar. What I do want to discuss is how to increase the
efficiency of the patch submission process so that senior committers
spend less of their time (our most critical resource) on poor quality
submissions (however that is judged) and also that patch submitters also
have fast feedback on missing requirements.

A clear FAQ entry or checklist can be applied easily by more casual
readers of the -patches list, allowing errors to be pointed out quickly
by non-committers and any missing requirements rectified. Written
guidelines are also much more easily translated than no guidelines at
all, benefiting non-native English speakers considerably.

Some of the above guidelines are clearly explained in FAQ, others not. I
would also want to add to the Developer page of the website something
along the lines of "Interested in developing for PostgreSQL? Please read
the <A>patch submission guidelines</A> before you begin work since only
the highest quality patches will be accepted."

I believe if we do this we will have more patches produced, reviewed and
committed from our available resources, as well as more hackers more
regularly willing to face the challenges of getting a quality patch
accepted. In the end we will live and die by the number of people
submitting and how many of those go on to become regular contributors
(should I say "serial hackers"?)

Bruce currently maintains much of this material, so I want it to be
known that this is specifically not a criticism of his work. This is
just an earnest attempt to increase the efficiency of the current
process, so patch authors can move quickly onto their next patch.

[Increasing the quality of my own submissions is a necessary act in this
process, though I hope these thoughts can be considered outside of my
own involvement and experience.]

It's probably also time for the annual discussion about when is the next
patch submission deadline. ;-)

Best Regards, Simon Riggs

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-02-14 17:45:31 Re: optimizer questions
Previous Message Martijn van Oosterhout 2006-02-14 16:47:22 Re: optimizer questions

Browse pgsql-patches by date

  From Date Subject
Next Message Andrew Klosterman 2006-02-14 19:06:03 Re: BUG #2246: Bad malloc interactions: ecpg, openssl
Previous Message Volkan YAZICI 2006-02-14 16:06:54 Re: BUG #2246: Bad malloc interactions: ecpg, openssl