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