DRAFT
The content of this page is a work in progress intended for review.

Please help improve the draft!

Ask questions or make suggestions in the discussion
or add your suggestions directly to this page.

This document describes the proposed process for code and release.

Code changes

Each code change shall be associated with a bug
Code changes shall be submitted as patches to the appropriate bug
Patches should be reviewed
When committing an r+ed patch, document the bug number you are addressing in the commit message
Aim for one commit per bug
Add the revision number of your commit to the relevant bug
Mark bugs that are fixed in trunk RESOLVED FIXED
QA will mark them RESOLVED VERIFIED after testing

Code freeze

Code freeze shall be announced by email when all bugs for the current release have been submitted
Code shall then be staged, QAed, and tested. (Note WebUI code is staged continuously and is available for QA after commit.)
Until QA is used to testing Socorro, a friendly "Please test Socorro" email sent to "mozwebqa@mozilla.org" with the appropriate milestone would be greatly appreciated; we'll take it from there, and run our BFT
After QA approval, a release shall be tagged from trunk.
Tags shall reside in the tags/ subversion directory. Suggested naming convention is release_svnversion_datetagged, for example, 1.6_r1900_20100329
Once the code is tagged, an email shall be sent announcing the tree is open again.

An IT bug shall be filed (a week before), referencing the tag and any instructions.
These instructions currently reside as incremental changes at SocorroUpgrade and from a fresh checkout perspective at Backend Install Frontend Install
Developers with major bugs or new features should be present during the push window, if at all possible.

How does this page relate to
- CodingConventions
- Changelog
- There is a wiki page (which I can't find on wiki, intranet, or code) that has a branching policy