Sandbox maintenance rules
- Always document your changes.
- Split different set of patches into different directories. It takes longer to find the set of files relating to one change if it is mixed in with 2 other patches.
- Keep the documentation current. Try to keep some track of your reasoning too. If I read in a README that change X wasn't a good idea after all it makes the reviewer wonder why.
- Document the status of your patch. It is important to know if this is an early test, or considered stable and workable by the author of the patch.
- All patches should be against the latest CVS version of Drupal, and include in the README when it was last synced.
- Don't use a sandbox for developing modules. There is a different directory structure for that.
- If your patch is 4 lines long don't bother to put it in a sandbox. Just file an issue against the Drupal project. Small patches are quick to check and find out if they work. Sandboxes should be for more extensive changes.
- Try to maintain patches in the sandbox. They are so much easier to check than compete files. If you are using CVS then you can use diff (cvs -H diff)
- Please make sure your script passes the code-style.pl script. It isn't perfect, and sometimes a bit too strict, but it will ensure some level of compliance with the coding standards.