diff --git a/doc/src/FAQ/FAQ_DEV.html b/doc/src/FAQ/FAQ_DEV.html index db41c11a6f..1ff58a7071 100644 --- a/doc/src/FAQ/FAQ_DEV.html +++ b/doc/src/FAQ/FAQ_DEV.html @@ -156,25 +156,65 @@

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 +

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

+ 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. + +
  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. + +
  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. + +
  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. + +
  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. + +
  6. Provide an implementation overview, preferably in code comments. + Following the surrounding code commenting style is usually a good + approach.
    7. + +
  7. New feature patches should also be accompanied by documentation + patches. If you need help checking the SQL standard, see 1.16.
    8. + +
  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. + +
  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.
    10. +
+ +

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?