Checkin Rules

• Make sure you have followed ChandlerCodingStyleGuidelines and understand PatchLifeCycle
• IMPORTANT: Make sure your stuff compiles and you can run Chandler - PreCheckInTests
• Proactively schedule and run your own design review and/or code review so that somebody else understands your code
• Before checkin, make sure the Tinderbox status shows green across the board - observe any special rules mentioned on Tinderbox.
• Write a meaningful comment for your checkin, and mention the bug number (if any) and code reviewer (if any) in the comments. Here's an example: "Bug 1234, fixed memory leak with repository delete, r=heikki."
• When you checkin, be on IRC (preferably) or on IM/Jabber/iChat/by the phone ready to fix any problems you caused
• Post checkin tests:
  • Check that you actually checked in what you meant to check in and that the comment was correct. There are several ways to do this. One is to review the commits message diff and click on the bug and confirm that you got to the right bug.
  • Mark the bug fixed (if your checkin was the last thing to close the bug). You should mention the revisions where the bug was fixed in the Bugzilla comment.
  • If you noticed error in checkin comment:
    • Post a message to dev
  • Update your whole tree, preferably a clean pull, build, and make sure that everything still works
• Monitor Tinderbox and make sure all machines cycle green

Once all platforms cycle green you are off-the-hook, so to speak.

If you break the build, add a notice to the Tinderbox Notice Board (there are links on Tinderbox), and start working on fixing it. If you can't fix it in a reasonable amount of time, back out your changes. (Bonsai can show you the commands to back out your changes if you are unsure what svn magic to utter, go to the query page, do your query, and the next page has a link at the top which says "Show commands which could be used to back out these changes".

If you see a broken build, do not check in except to fix the tree. First, see if the person who checked in is around. If not, see if you can figure out and fix the issue in a few minutes. If not, and the build has been broken a few hours, back out the checkin that caused the problem. Then send an email to the author to inform them their change was backed out.