These are some rules that should allow to maximize the outcome of the efforts of multiple developers and help to avoid 'bad interaction' of several people working on the same sources. They are suggestions, but I (Steffen Seeger) think they are reasonable to stick to.


*** NEW *** Additional Namespace rules 
Using CVS
  1. Run 'cvs -n update -PAd ggi' before you start commiting changes to the repository. Save the stderr and stdout output and study them carefully if you have told CVS about all files you want to add to or delete from the repository. This also lists the files that you have modified, so analyze carefully if you really want to commit changes to the main repository. For instance QuickHacks you made during tracing down a bug must not end up in the repository. This doesn't mean you should not add debugging code, this is actually strongly recommended, but you should care not to break other peoples work accidently.
  2. Think twice times twice times (no typo! Think four times!) before commiting directory structures and before placing new files anywhere in the repository. CVS is very unkind if you want to change the direcory structure lateron Even if it be moving a directory up one level in the tree. If this happens to be neccessary anyway, contact the repository maintainer.
  3. If you have fixed some obvious minor bugs such as typos etc., commit them and mail the maintainers of the files changed a short bugreport. This is just that the maintainer knows about the changes you made.
  4. Before commiting fixes for major bugs that require rewriting some functions or fundamental changes discuss this with the maintainer things you discovered as bugs actually might not be real bugs or require other things.
  5. CVS does not substitute communication between developers. Keep this always in mind!

Coding Style

Each programmer has its own style of coding, but if there are more than one working on the same project, it's quite useful to stick to one coding style. For the GGI project the following rules should help to produce the the style used. These are manly designed to enhance readability. You usually write code once but read it a hundred times. And if not you, certainly other people will (have to) do. So, make your code readable!