Patch Submission Guidelines - Mailing list pgsql-hackers
From | Simon Riggs |
---|---|
Subject | Patch Submission Guidelines |
Date | |
Msg-id | 1139937655.1258.1004.camel@localhost.localdomain Whole thread Raw |
Responses |
Re: Patch Submission Guidelines
|
List | pgsql-hackers |
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
pgsql-hackers by date: