QA/QMO/Planning: Difference between revisions
Jump to navigation
Jump to search
| Line 31: | Line 31: | ||
## Prioritize those bugs | ## Prioritize those bugs | ||
# Talk to WebDev for scheduling of release and resources | # Talk to WebDev for scheduling of release and resources | ||
# | #* Create wiki for resource and tentative schedule of beta, qa and release under QMO/ | ||
# 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/ | # 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 | #* Request any changes needed on other branches under the folder as necessary for the release | ||
Revision as of 18:53, 3 June 2010
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
Milestone Release
- Determine concept of next release
- File or triage bugs to fix associated to concept
- Prioritize those bugs
- Talk to WebDev for scheduling of release and resources
- Create wiki for resource and tentative schedule of beta, qa and release under QMO/
- 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
- Bugs are only committed to stage
- Bugs are verified on stage before the push
- 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
- Code from verified bugs is committed to production on (or very close) to push date
- Bugs are re-verified on production after the push
- Bugs that have not been committed to production are postponed to the next milestone
- Promote release via blog post with new features
- Run a post-mortem on release
Security Release Checklist
- Security related bugs are committed to stage
- Security related bugs are verified on stage
- Security related bugs are committed to production. Other bug fix code on stage will not be committed to production.