From: Bruce Momjian Date: Thu, 2 Mar 2006 18:18:13 +0000 (+0000) Subject: Add to TODO.detail for qsort. X-Git-Tag: REL8_2_BETA1~1338 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=1fa33539abf122ae206eb9c00b9dddeadcb8d5d7;p=postgresql Add to TODO.detail for qsort. --- diff --git a/doc/TODO.detail/qsort b/doc/TODO.detail/qsort new file mode 100644 index 0000000000..321babd27f --- /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).

+! +!

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.

+ +

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 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: +!

    +!
  1. 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.
    2. +! +!
  2. 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.
    3. +! +!
  3. 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.
    4. +! +!
  4. 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.
    5. +! +!
  5. 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
    6. +! +!
  6. 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.
    7. +! +!
  7. Provide an implementation overview, preferably in code comments.
    8. +! +!
  8. 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.
    9. +! +!
  9. 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.
    10. +! +!
  10. 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.
    11. +! +!
  11. If your patch changes any existing defaults, you will need to +! explain why this is *required* or the patch will likely be rejected.
    12. +!
+! +!

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?