Developer's Frequently Asked Questions (FAQ) for PostgreSQL
- Last updated: Sat Dec 24 14:29:33 EST 2005
+ Last updated: Wed Mar 1 17:24:48 EST 2006
Current maintainer: Bruce Momjian (pgman@candle.pha.pa.us)
1.5) I've developed a patch, what next?
- Generate the patch in contextual diff format. If you are unfamiliar
- with this, you might find the script src/tools/makediff/difforig
- useful. Unified diffs are only preferrable if the file changes are
- single-line changes and do not rely on the surrounding lines.
-
- Ensure that your patch is generated against the most recent version of
- the code. If it is a patch adding new functionality, the most recent
- version is CVS HEAD; if it is a bug fix, this will be the most
- recently version of the branch which suffers from the bug (for more on
- branches in PostgreSQL, see 1.15).
-
- Finally, submit the patch to pgsql-patches@postgresql.org. It will be
- reviewed by other contributors to the project and will be either
- accepted or sent back for further work. Also, please try to include
- documentation changes as part of the patch. If you can't do that, let
- us know and we will manually update the documentation when the patch
- is applied.
+ You will need to submit the patch to pgsql-patches@postgresql.org. It
+ will be reviewed by other contributors to the project and will be
+ either accepted or sent back for further work. To help ensure your
+ patch is reviewed and committed in a timely fashion, please try to
+ make sure your submission conforms to the following guidelines:
+ 1. Ensure that your patch is generated against the most recent
+ version of the code, which for developers is CVS HEAD. For more on
+ branches in PostgreSQL, see 1.15.
+ 2. Try to make your patch as readable as possible by following the
+ project's code-layout conventions. This makes it easier for the
+ reviewer, and there's no point in trying to layout things
+ differently than pgindent. Also avoid unnecessary whitespace
+ changes because they just distract the reviewer, and formatting
+ changes will be removed by the next run of pgindent.
+ 3. The patch should be generated in contextual diff format (diff -c
+ and should be applicable from the root directory. If you are
+ unfamiliar with this, you might find the script
+ src/tools/makediff/difforig useful. (Unified diffs are only
+ preferable if the file changes are single-line changes and do not
+ rely on surrounding lines.)
+ 4. PostgreSQL is licensed under a BSD license, so any submissions
+ must conform to the BSD license to be included. If you use code
+ that is available under some other license that is BSD compatible
+ (eg. public domain) please note that code in your email submission
+ 5. Confirm that your changes can pass the regression tests. If your
+ changes are port specific, please list the ports you have tested
+ it on.
+ 6. Provide an implementation overview, preferably in code comments.
+ Following the surrounding code commenting style is usually a good
+ approach.
+ 7. New feature patches should also be accompanied by documentation
+ patches. If you need help checking the SQL standard, see 1.16.
+ 8. If you are adding a new feature, confirm that it has been tested
+ thoughly. Try to test the feature in all conceivable scenarios.
+ 9. If it is a performance patch, please provide confirming test
+ results to show the benefit of your patch. It is OK to post
+ patches without this information, though the patch will not be
+ applied until somebody has tested the patch and found a
+ significant performance improvement.
+
+ Even if you pass all of the above, the patch might still be rejected
+ for other reasons. Please be prepared to listen to comments and make
+ modifications.
+
+ You will be notified via email when the patch is applied, and your
+ name will appear in the next version of the release notes.
1.6) Where can I learn more about the code?
projects / postgresql / commitdiff