On Tuesday 14 February 2006 20:42, Robert Treat wrote:
> On Tuesday 14 February 2006 16:00, Martijn van Oosterhout wrote:
> > > I would like to suggest that we increase substantially the FAQ entries
> > > relating to patch submission. By we, I actually mean please could the
> > > committers sit down and agree some clarified written guidelines?
> >
> > As I remember, there is a disinclination to increase the size of the
> > FAQ very much. This suggests maintaining it as a seperate document. Or
> > alternatively attach it as an appendix to the main documentation.
>
> Huh? The current developers FAQ is at least 1/2 the size of the main FAQ.
> I think adding a submission on patch submission guidelines is a great idea.
> I'll have a patch based on Simon's post to -patches ready in the next 24
> hours unless someone is really going to object.
As stated, the following patch adds a list of patch submission guidelines
based on Simon Riggs suggestions to the developers FAQ.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Index: doc/src/FAQ/FAQ_DEV.html
===================================================================
RCS file: /projects/cvsroot/pgsql/doc/src/FAQ/FAQ_DEV.html,v
retrieving revision 1.107
diff -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 16 Feb 2006 04:44:57 -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,226 ----
<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 fasion, please make sure your
! submission conforms to the following guidelines before sending your email:
! <ol>
! <li>Has patch been discussed previously? If it has, give a direct link
! to the message and/or bug# from the mail archives
! (<a href="http://archives.postgresql.org/";>http://archives.postgresql.org/</a>).
! If it has not and the patch is of any complexity it is strongly
! recommended you post a message to the appropriate list or you risk
! getting your patch rejected. Refer back to <a href="#1.4">1.4</a> for
! email guidelines.</li>
!
! <li>Ensure that your patch is generated against the most recent version
! of the code. If you are developing new features, this should be
! CVS HEAD; if it is a bug fix, this will be the most recent version of
! the branch which suffers from the bug. For more on branches in
! PostgreSQL, see <a href="#1.15">1.15</a>.</li>
!
! <li>The patch should be generated in contextual diff format 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 preferrable if the file changes are
! single-line changes and do not rely on the 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 make check and list the
! platforms you have tested this on. If your changes are port specific,
! list the ports that it applies to.</li>
!
! <li>Provide an implementation overview, preferably in code comments.</li>
!
! <li>If it is a performance patch, provide confirming test results to
! show the benefits of your patch. It is OK to post patches without
! this information, though the patch will not be applied until *somebody*
! has tested the patches and found a valuable performance effect directly
! attributable to the patch. Given that writing performance tests is not
! terribly exciting, it is recommended you take this task upon yourself.</li>
!
! <li>If it is a new feature patch, confirm that it has been tested for
! all desired scenarios. If it has not, this should be clearly stated as
! a request for a particular kind of test to be performed. Note that the
! patch will go no further until that test has been performed.</li>
!
! <li>If your patch changes any existing defaults, you will need to
! explain why this is *required* or the patch will likely be rejected.
! New feature patches should also be accompanied by doc patches, and
! pointers to any relevant sections of the SQL standard are recommended
! as well. See <a href="#1.16">1.16</a> for more information on the
! SQL standards</li>
! </ol>
!
! <p>Even if you pass all of the above, the patch may still be rejected
! for other technical reasons. You should be prepared to listen to
! comments received and perform any agreed rework. Even if you have
! received positive comments from some community members, others may spot
! problems with your approach, coding style or many other issues.</p>
!
! <p>Successful patches will be notified to you by email and you will be
! credited for that work in the next set of release notes.</p>
<H3 id="item1.6">1.6) Where can I learn more about the
code?</H3>
***************
*** 999,1004 ****
--- 1045,1051 ----
in the <I>pgsql/data</I> directory. The client profile file will be
put in the client's current directory. Linux requires a compile with
<I>-DLINUX_PROFILE</I> for proper profiling.</P>
+
</BODY>
</HTML>
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
