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

Add language about rights given by posting a patch:

Browse Source 
<li>PostgreSQL is licensed under a BSD license.  By posting a patch
    to the public PostgreSQL mailling lists, you are giving the PostgreSQL
    Global Development Group the non-revokable right to distribute your
    patch under the BSD license.  If you use code that is available under
    some other license that is BSD compatible (eg. public domain), please
    note that in your email submission.</li>
This commit is contained in:
Bruce Momjian 2007-02-28 17:28:09 +00:00
parent 2c6feff5e7
commit d1ce4f7396
2 changed files with 25 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
doc/FAQ_DEV
View File

@ -1,7 +1,7 @@
Developer's Frequently Asked Questions (FAQ) for PostgreSQL Developer's Frequently Asked Questions (FAQ) for PostgreSQL
Last updated: Tue Feb 27 18:12:31 EST 2007 Last updated: Wed Feb 28 12:27:44 EST 2007
Current maintainer: Bruce Momjian (bruce@momjian.us) Current maintainer: Bruce Momjian (bruce@momjian.us)
@ -136,20 +136,22 @@ General Questions
src/tools/make_diff/difforig useful. (Unified diffs are only src/tools/make_diff/difforig useful. (Unified diffs are only
preferable if the file changes are single-line changes and do not preferable if the file changes are single-line changes and do not
rely on surrounding lines.) rely on surrounding lines.)
4. PostgreSQL is licensed under a BSD license, so any submissions 4. PostgreSQL is licensed under a BSD license. By posting a patch to
must conform to the BSD license to be included. If you use code the public PostgreSQL mailling lists, you are giving the
that is available under some other license that is BSD compatible PostgreSQL Global Development Group the non-revokable right to
(eg. public domain) please note that code in your email submission distribute your patch under the BSD license. If you use code that
is available under some other license that is BSD compatible (eg.
public domain), please note that in your email submission.
5. Confirm that your changes can pass the regression tests. If your 5. Confirm that your changes can pass the regression tests. If your
changes are port specific, please list the ports you have tested changes are port specific, please list the ports you have tested
it on. it on.
6. Provide an implementation overview, preferably in code comments. 6. If you are adding a new feature, confirm that it has been tested
Following the surrounding code commenting style is usually a good thoroughly. Try to test the feature in all conceivable scenarios.
approach.
7. New feature patches should also be accompanied by documentation 7. New feature patches should also be accompanied by documentation
patches. If you need help checking the SQL standard, see 1.16. 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 8. Provide an implementation overview, preferably in code comments.
thoroughly. Try to test the feature in all conceivable scenarios. Following the surrounding code commenting style is usually a good
approach.
9. If it is a performance patch, please provide confirming test 9. If it is a performance patch, please provide confirming test
results to show the benefit of your patch. It is OK to post results to show the benefit of your patch. It is OK to post
patches without this information, though the patch will not be patches without this information, though the patch will not be

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

@ -13,7 +13,7 @@
<H1>Developer's Frequently Asked Questions (FAQ) for <H1>Developer's Frequently Asked Questions (FAQ) for
PostgreSQL</H1> PostgreSQL</H1>
<P>Last updated: Tue Feb 27 18:12:31 EST 2007</P> <P>Last updated: Wed Feb 28 12:27:44 EST 2007</P>
<P>Current maintainer: Bruce Momjian (<A href= <P>Current maintainer: Bruce Momjian (<A href=
"mailto:bruce@momjian.us">bruce@momjian.us</A>)<BR> "mailto:bruce@momjian.us">bruce@momjian.us</A>)<BR>
@ -190,26 +190,28 @@
preferable if the file changes are single-line changes and do not preferable if the file changes are single-line changes and do not
rely on surrounding lines.)</li> rely on surrounding lines.)</li>
<li>PostgreSQL is licensed under a BSD license, so any submissions must <li>PostgreSQL is licensed under a BSD license. By posting a patch
conform to the BSD license to be included. If you use code that is to the public PostgreSQL mailling lists, you are giving the PostgreSQL
available under some other license that is BSD compatible (eg. public Global Development Group the non-revokable right to distribute your
domain) please note that code in your email submission</li> patch under the BSD license. If you use code that is available under
some other license that is BSD compatible (eg. public domain), please
note that in your email submission.</li>
<li>Confirm that your changes can pass the regression tests. If your <li>Confirm that your changes can pass the regression tests. If your
changes are port specific, please list the ports you have tested it changes are port specific, please list the ports you have tested it
on.</li> on.</li>
<li>Provide an implementation overview, preferably in code comments. <li>If you are adding a new feature, confirm that it has been tested
Following the surrounding code commenting style is usually a good thoroughly. Try to test the feature in all conceivable
approach.</li> scenarios.</li>
<li>New feature patches should also be accompanied by documentation <li>New feature patches should also be accompanied by documentation
patches. If you need help checking the SQL standard, see <a href= patches. If you need help checking the SQL standard, see <a href=
"#item1.16">1.16</a>.</li> "#item1.16">1.16</a>.</li>
<li>If you are adding a new feature, confirm that it has been tested <li>Provide an implementation overview, preferably in code comments.
thoroughly. Try to test the feature in all conceivable Following the surrounding code commenting style is usually a good
scenarios.</li> approach.</li>
<li>If it is a performance patch, please provide confirming test <li>If it is a performance patch, please provide confirming test
results to show the benefit of your patch. It is OK to post patches results to show the benefit of your patch. It is OK to post patches