Robert Treat wrote: > On Thursday 16 February 2006 00:27, Tom Lane wrote: > > Robert Treat <[EMAIL PROTECTED]> writes: > > > As stated, the following patch adds a list of patch submission guidelines > > > based on Simon Riggs suggestions to the developers FAQ. > > > > A couple minor comments ... > > > > Attached patch updated based on previous feedback.
I have applied your patch (attached) after some cleanup, and applied to 8.1.X too. The only part I removed was the requirement to research previous discussion of the patch. That usually is not an issue, and can always be requested after the patch is submitted. Thanks, nice improvement. -- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http://www.sraoss.com + If your life is a hard drive, Christ can be your backup. +
Index: doc/src/FAQ/FAQ_DEV.html =================================================================== RCS file: /cvsroot/pgsql/doc/src/FAQ/FAQ_DEV.html,v retrieving revision 1.107 diff -c -c -r1.107 FAQ_DEV.html *** doc/src/FAQ/FAQ_DEV.html 24 Dec 2005 19:29:38 -0000 1.107 --- doc/src/FAQ/FAQ_DEV.html 1 Mar 2006 22:20:01 -0000 *************** *** 156,180 **** <H3 id="item1.5">1.5) I've developed a patch, what next?</H3> ! <P>Generate the patch in contextual diff format. If you are unfamiliar with this, you might find the script ! <I>src/tools/makediff/difforig</I> useful. Unified diffs are ! only preferrable if the file changes are single-line changes and ! do not rely on the surrounding lines.</P> ! ! <P>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 <A href= ! "#1.15">1.15</A>).</P> ! <P>Finally, submit the patch to [EMAIL PROTECTED] 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.</P> <H3 id="item1.6">1.6) Where can I learn more about the code?</H3> --- 156,220 ---- <H3 id="item1.5">1.5) I've developed a patch, what next?</H3> ! <P>You will need to submit the patch to [EMAIL PROTECTED] 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: ! ! <ol> ! <li>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 <a href="#1.15">1.15</a>.</li> ! ! <li>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.</li> ! ! <li>The patch should be generated in contextual diff format (<i>diff ! -c</i> and should be applicable from the root directory. If you are unfamiliar with this, you might find the script ! <I>src/tools/makediff/difforig</I> useful. (Unified diffs are only ! preferable if the file changes are single-line changes and do not ! rely on surrounding lines.)</li> ! ! <li>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</li> ! ! <li>Confirm that your changes can pass the regression tests. If your ! changes are port specific, please list the ports you have tested it ! on.</li> ! ! <li>Provide an implementation overview, preferably in code comments. ! Following the surrounding code commenting style is usually a good ! approach.</li> ! ! <li>New feature patches should also be accompanied by documentation ! patches. If you need help checking the SQL standard, see <a href= ! "#1.16">1.16</a>.</li> ! ! <li>If you are adding a new feature, confirm that it has been tested ! thoughly. Try to test the feature in all conceivable ! scenarios.</li> ! ! <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 ! without this information, though the patch will not be applied until ! somebody has tested the patch and found a significant performance ! improvement.</li> ! </ol> ! ! <p>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.</p> ! <p>You will be notified via email when the patch is applied, and ! your name will appear in the next version of the release notes.</p> <H3 id="item1.6">1.6) Where can I learn more about the code?</H3>
---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly