database/postgres
database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-04-20 00:42:27 +03:00
Code

Update FAQ_DEV text file.

Browse Source
This commit is contained in:
Bruce Momjian 2006-03-01 22:25:36 +00:00
parent 88a4314bb1
commit 15516c5f0b
3 changed files with 48 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
doc/FAQ_AIX
View File

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

63
doc/FAQ_DEV
View File

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

2
doc/src/FAQ/FAQ_DEV.html
View File

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