Commit Guidelines

General Guidelines

• Try to break larger changes into smaller patches/commits when possible.
• Do not mix unrelated cleanup and feature changes or bug fixes in the same patch/commit.
• As a general rule, only fix the coding style of lines you edit, but not that of any other lines.
• Please make sure the commit message starts with a short one-line description (ideally less than 80 characters) of the changes. That makes it much easier to find commits or write a good changelog.

Guidelines for Non Member Contributions

1. ​Install git if it is not already installed.
2. If you have no idea how to use git you may want to read ​Git for beginners: The definitive practical guide and our Git Howto; the rest of these steps assume some basic knowledge of git and the presence of a local clone made as described on the Git Howto.
3. Read the Compile Guide (and the guide for your operating system).
4. Get setup on ​github.
   1. If you do not already have a github account, ​get one.
   2. ​Generate a keypair.
   3. ​Set your user and email in git; this is very important because it controls how you get credited!
   4. ​Fork the ​Warzone Repo on github.
   5. Set up your personal fork to mirror your local repo.

      git remote add --mirror <name> <ssh-url-to-your-fork>
      

5. Create a local branch to hold your changes.
   • If your commits address a existing ticket add a line at the end of your commit messages that says: Refs #1234 or Fixes #1234 (for #1234) as appropriate (see ​command guidelines for more details).
6. Push your commits to your fork.

   git push <name>
   

7. Make a ticket that gives a high level overview of your changes.
   • Or add it to an existing ticket as appropriate.
   • Create and attach your patch as either a diff or a patch serial to the ticket.
   • Include a descriptive summary of the changes, and also a short sentence that can be used in the changelog.

Once you have done this your changes will be reviewed; they may be accepted as is or modification and/or clarification may be requested before they are merged in.

If you think your changes may be controversial ask for a Project Member's opinion first.

Guidelines for Project Members

• Patches as a rule go into trac. Give a quick run down of what it does and what it changes.
• If a subsystem of the code has its own maintainer, that person is free to make commits to this code without posting to the list first.
• Patches that only fix bugs (no rewrites which fix bugs...) or build errors can go in at once.
• Patches that alter documentation can go in at once.
• Patches that have been reviewed (signed-off) by another developer can go in at once. Put the name of the reviewer in the commit message.
• After a patch has been put into the patch tracker, give the development list 48 hours to comment on it.
• Update the changelog when the patch is integrated.