Add to TODO.detail for qsort.

doc/TODO.detail/qsort

+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 ****
+      
+      <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 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.</P>
+  
+      <H3 id="item1.6">1.6) Where can I learn more about the
+      code?</H3>
+--- 156,231 ----
+      
+      <H3 id="item1.5">1.5) I've developed a patch, what next?</H3>
+  
+!     <P>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 fasion, please try to make sure your 
+! 	submission conforms to the following guidelines:
+! 	<ol>
+! 		<li>Has the 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, 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. 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.</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.</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 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>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>
+! 
+! 		<li>If your patch changes any existing defaults, you will need to 
+! 		explain why this is *required* or the patch will likely be rejected.</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>