Update FAQ_DEV text file.

doc/FAQ_AIX

@@ -1,5 +1,5 @@
 From: Zeugswetter Andreas <ZeugswetterA@spardat.at>
-$Date: 2006/03/01 22:23:49 $
+$Date: 2006/03/01 22:25:36 $
 
 On AIX 4.3.2 PostgreSQL compiled with the native IBM compiler xlc
 (vac.C 5.0.1) passes all regression tests.  Other versions of OS and

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
+   You will need to submit the patch to pgsql-patches@postgresql.org. It
-   with this, you might find the script src/tools/makediff/difforig
+   will be reviewed by other contributors to the project and will be
-   useful. Unified diffs are only preferrable if the file changes are
+   either accepted or sent back for further work. To help ensure your
-   single-line changes and do not rely on the surrounding lines.
+   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.
        
-   Ensure that your patch is generated against the most recent version of
+   Even if you pass all of the above, the patch might still be rejected
-   the code. If it is a patch adding new functionality, the most recent
+   for other reasons. Please be prepared to listen to comments and make
-   version is CVS HEAD; if it is a bug fix, this will be the most
+   modifications.
-   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
+   You will be notified via email when the patch is applied, and your
-   reviewed by other contributors to the project and will be either
+   name will appear in the next version of the release notes.
-   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.
    
   1.6) Where can I learn more about the code?
   

doc/src/FAQ/FAQ_DEV.html

@@ -13,7 +13,7 @@
     <H1>Developer's Frequently Asked Questions (FAQ) for
     PostgreSQL</H1>
 
-    <P>Last updated: Sat Dec 24 14:29:33 EST 2005</P>
+    <P>Last updated: Wed Mar  1 17:24:48 EST 2006</P>
 
     <P>Current maintainer: Bruce Momjian (<A href=
     "mailto:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us</A>)<BR>