Patches should be attached to the relevant bug in the Scoop Bug Muncher, at http://bugz.mostly-harmless.ca/. If you have a patch for a new feature which has no corresponding bug in the bug muncher, create the bug, assign it to yourself, then attach the file. Please note that if you want the attachment to be reviewed you should set the `review?' flag on the attachment. That flag is used in searches and makes it easier for us to distinguish between patches already tested and those that aren't. By setting the review? flag, you will also get an email notice when the patch is tested and either approved (review+) or rejected (review-) by the maintainers.
Only send patches against the most recent cvs tree! Patches against older code will not be accepted. To make sure you are developing from the most recent code, do a `cvs update -dPA' in your scoop/ directory.
Create your code patches using the `cvs diff -u' command, and issue that command in the scoop/ directory (not in the subdirectory containing the file you were working in) to make sure the patch contains all your changes. You probably want to redirect the output of that command into an appropriately named file. Note that these rules are to make it easier for the maintainers to read and apply your patch!
If any changes to the database are required, submit a database patch with all the SQL commands required to make those changes. The syntax is exactly the same as it is in the mysql client, so it's a good idea to create the patch as you make the database changes, and copy/paste the SQL commands you use into the patch file.
Remember that many blocks, boxes, and site controls that already exist may have been changed by a given site, and that if you are making significant changes to any of those that could break an established site, you probably want a db upgrade script that will test the site and make the changes as appropriate. You can look at the scripts in the scoop/struct/patch-files directories for examples.