(see also How To Review Patches)

Please create a new ticket to track the issue unless your patch is a patch for an issue that is already ticketed.

Then run the following darcs commands to generate a darcs patch file named WHAT.darcs.patch:

  darcs record
  darcs send -o WHAT.darcs.patch http://tahoe-lafs.org/source/tahoe-lafs/trunk

(The name of the file, which is given here as WHAT.darcs.patch, is not that important. Use a relevant word or two or maybe the ticket number.)

Write a descriptive patch name and description like these ones (the "patch name" and "patch description" are labelled on these pages as "Message"): 8ba536319689ec8e, 1de4d2c594ee64c8, d0706d27ea2624b5, 63b28d707b12202f, c18b934c6a8442f8, 7cadb49b88c03209, be6139dad72cdf49. If, and only if, a single file was modified in the patch it is conventional to begin the "patch name" field with "<FILENAME>:"

Attach the patch to the ticket.

Please use a filename like *.darcs.patch so that Trac will display it with proper syntax highlighting.

Or without darcs you can attach a normal old unified diff. If you do that, please use a filename like *.diff so that Trac will display it with syntax highlighting. (If using darcs, you can generate a unified diff with darcs whatsnew --unified.)

Then add the keyword review-needed (spelled just like that) to the Keywords field of the ticket.

Design reviews

To request a design review, explain your design (with or without a patch) and then add the design-review-needed tag. Completion of a design review will normally not directly result in a patch being committed. The main goal of a design review is to give the person working on the ticket confidence that there are no show-stopping issues with the approach they are taking, and to get feedback on smaller issues that are useful to take into account before doing further work on a patch.