Add to TODO.detail for qsort.

diff --git a/doc/TODO.detail/qsort b/doc/TODO.detail/qsort
new file mode 100644 (file)
index 0000000..321babd
--- /dev/null
+++ b/doc/TODO.detail/qsort
@@ -0,0 +1,111 @@
+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 20:08:51 -0000
+***************
+*** 156,180 ****
+      
+      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.
+! 
+!     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">1.15).
+! 
+!     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.
+  
+      1.6) Where can I learn more about the
+      code?
+--- 156,231 ----
+      
+      1.5) I've developed a patch, what next?
+  
+!     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 try to make sure your 
+!  submission conforms to the following guidelines:
+!  
+!      Has the patch been discussed previously? If it has, give a direct link 
+!      to the message and/or bug# from the mail archives 
+!      (http://archives.postgresql.org/). 
+!      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 1.4 for 
+!      email guidelines.
+!  
+!      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.
+! 
+!      Try to make your patch as readable as possible. Try to follow the 
+!      project's code-layout conventions; again, this makes it easier for the 
+!      reviewer, and there's no point in trying to do it 
+!      differently than pgindent.  Also avoid unnecessary whitespace 
+!      changes, they just distract the reviewer, and your formatting changes 
+!      will probably not survive the next pgindent run anyway.
+! 
+!      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 src/tools/makediff/difforig 
+!      useful.
+!  
+!      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
+! 
+!      Confirm that your changes can pass the regression tests and list the 
+!      platforms you have tested this on. If your changes are port specific, 
+!      list the ports that it applies to.
+! 
+!      Provide an implementation overview, preferably in code comments.
+! 
+!      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.
+! 
+!      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.
+! 
+!      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 1.16 for more information on the 
+!      SQL standards.
+! 
+!      If your patch changes any existing defaults, you will need to 
+!      explain why this is *required* or the patch will likely be rejected. 
+!  
+! 
+!  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.
+! 
+!  Successful patches will be notified to you by email and you will be
+!  credited for that work in the next set of release notes.
+  
+      1.6) Where can I learn more about the
+      code?