Support/1.0 Postmortem: Difference between revisions
< Support
Jump to navigation
Jump to search
(Created page with '= What went well = * We hit all our Q1 goals and delivered 1.0! = What we can do better = * Deadlines further from end of quarter (already planning for this) * Discipline with b...') |
No edit summary |
||
| Line 8: | Line 8: | ||
** After freeze, no changes to prod branch until tagged. (Committing stuff to trunk is fine.) | ** After freeze, no changes to prod branch until tagged. (Committing stuff to trunk is fine.) | ||
** Why do we do this? 1) to prevent regressions and other unforseen problems 2) to give QA time to do their jobs 3) to keep prod consistent | ** Why do we do this? 1) to prevent regressions and other unforseen problems 2) to give QA time to do their jobs 3) to keep prod consistent | ||
* Improving QA | |||
**Make a list of critical milestone bugs to verify after a push (e.g. bug 484243) | |||
**Automated tests ([https://wiki.mozilla.org/QA/Execution/Web_Testing/SUMO/Selenium already working on this]) | |||
* Improving efficiency | |||
** Prioritize work according to milestones and priority (P1, P2, ...). Always good to think about future bugs, but actually fixing or submitting patches for bugs that are targeted as Future or a later milestone than the current is not working according to our priorities. | |||
** Even better PRDs | |||
Revision as of 15:27, 7 April 2009
What went well
- We hit all our Q1 goals and delivered 1.0!
What we can do better
- Deadlines further from end of quarter (already planning for this)
- Discipline with build process:
- Reviews for patches: on every non trivial patch. ask someone who knows. If you are asked and aren't confident/comfortable, pass review to someone else. No commit without review for anything other than minor cosmetic patches.
- After freeze, no changes to prod branch until tagged. (Committing stuff to trunk is fine.)
- Why do we do this? 1) to prevent regressions and other unforseen problems 2) to give QA time to do their jobs 3) to keep prod consistent
- Improving QA
- Make a list of critical milestone bugs to verify after a push (e.g. bug 484243)
- Automated tests (already working on this)
- Improving efficiency
- Prioritize work according to milestones and priority (P1, P2, ...). Always good to think about future bugs, but actually fixing or submitting patches for bugs that are targeted as Future or a later milestone than the current is not working according to our priorities.
- Even better PRDs