Source Control Rules

The rules of engagement for the source control system are easy, but I'll kick out everyone (independent of celebrity or other honorary status) not following them. (Omar Shahine)

1.   If you are not sure whether you should/could/may add or change something, ask on the Developer Mailing List. Behave like a professional software developer, please -- even if you aren't one.

2.   Learn how to use CVS. ALWAYS DO A CVS UPDATE before checking in.

3.   All work is done in the "source" subtree. When we plan to turn "source" into a new release we will tag the source

4.   Unit Tests ALWAYS pass.

5.   If you want to add a feature or fix a bug, we expect that you understand what you're doing. If you have a big feature in the work you must add it here:  TBD

6.   Checked-In items compile, work as expected and add features, not remove features. The checked-in code ALWAYS builds. Checking in functionality that doesn't build should be avoided at all costs.

7.   Any new feature that you add must be configurable. So, either you extend the macros classes to allow a user to embed (or not to embed) your new element or if you change the engine behavior, add an appropriate switch to site.config and an appropriate handler. The default value for switches for new features is "false" (unless there is a compelling reason for it to be true, ask an admin if you are not sure). if you want that users can easily switch it on, add it to the appropriate section in the configuration page.

8.   If you have GPL code in your pocket coming in, leave it at the door, please.

9.   This list may grow!