diff options
Diffstat (limited to 'doc/FAQ_DEV')
| -rw-r--r-- | doc/FAQ_DEV | 65 |
1 files changed, 47 insertions, 18 deletions
diff --git a/doc/FAQ_DEV b/doc/FAQ_DEV index e0eb5df1b2a..77fe10d3776 100644 --- a/doc/FAQ_DEV +++ b/doc/FAQ_DEV @@ -1,7 +1,7 @@ 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) @@ -108,23 +108,52 @@ General Questions 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? |