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.
- 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 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 "firstname.lastname@example.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.