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
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 |
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 |