QA/QMO/Planning

Definitions

• Milestone release = a release made up of any number of bugs that are part of a goal for QMO
• Security release = a small and quick release made up of security bugfixes ONLY. A security release is not part of the milestone releases (no milestone number is required here)
• Push = pushing the code changes from the SVN production branch to the live site.
• P1 Page: Page linked to on the main navigation bar and/or one-hop away from the home page
• P2 Page: Page NOT linked to on the main navigation bar and at least 2 hops away from the home page

Composition of Release

Major Milestone Releases (i.e. x in x.0.0)

• Functional changes
• Add/Remove of pages
• Add/Remove snippets on P1 pages
• Bug fixes
• Add/Remove snippets on P2 and lower pages

Minor Milestone Releases (i.e. y in x.y.0)

• Iterative features
• Bug fixes
• Add/Remove snippets on P2 and lower pages

Security Releases (i.e. z in x.y.z)

• Security Bug Fixes

Release Checklists

Milestone Release Checklist

Get Ready

1. Determine concept of next release
   1. File or triage bugs to fix associated to concept
   2. Prioritize those bugs
2. Talk to WebDev for scheduling of release and resources
   • Create wiki for resource and tentative schedule of beta, qa and release under QMO/
3. Get subversion and admin (to WordPress) access to staging for developer (with his/her e-mail) if new under a branch in http://svn.mozilla.org/projects/quality.mozilla.org/
   • Request any changes needed on other branches under the folder as necessary for the release
   • example: https://bugzilla.mozilla.org/show_bug.cgi?id=560343
   • Determine if changes need to be made to .htaccess

Get Set

1. Bugs are only committed to stage
2. Bugs are verified on stage before the push

Go

1. Notify IT with a bug of push to production
   • include date, folder/commits content that will be sent to production, if archive of previous release is necessary and where
2. Code from verified bugs is committed to production on (or very close) to push date
3. Bugs are re-verified on production after the push
4. Bugs that have not been committed to production are postponed to the next milestone
5. Promote release via blog post with new features
6. Run a post-mortem on release

Security Release Checklist

1. Security related bugs are committed to stage
2. Security related bugs are verified on stage
3. Notify IT with a bug of push to production
   • include date, commit that will be sent to production
4. Security related bugs are committed to production. Other bug fix code on stage will not be committed to production