Release Management/Triage Proposal

From MozillaWiki
< Release Management
Revision as of 18:47, 12 October 2011 by Akeybl (talk | contribs) (Created page with "===Goals=== * Triage all Aurora/Beta bugs within 5 days of the request * Only percolate up the bugs with questions to the group (for better time utilization) * Keep track of the...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Goals

  • Triage all Aurora/Beta bugs within 5 days of the request
  • Only percolate up the bugs with questions to the group (for better time utilization)
  • Keep track of the outcome of triage sessions, discuss outside of weekly meetings

Meetings

  • Mon/Wed/Fri @ 4PM
    • Mon/Wed - Beta first
    • Fri - Aurora first
    • Anyone can drop in on vidyo and participate
    • Triage rollups
  • Tue/Thu @ 2PM
    • Not specific to Aurora or Beta
    • Review any outstanding bugs that needed attention, starting with Beta on Tue and Aurora on Thu
    • Anyone can drop in on vidyo and participate
  • To prevent delay, the last weekend before release may require additional triaging

Processes

  • Engineer nominations for tracking
  • Engineer requests for approval
  • Triage rollups
    • split out by product?
    • split out by tracking/approval
    • split into what action was taken: +, -, question in bug, question of group (policy decisions, etc.)
    • sent to (new) public list, allowing for discussion of "unsure" bugs prior to Tue/Thu meetings, allows inclusion of those otherwise not involved
    • security rollups sent to (new) private list (including secteam for comment?)

Tools

  • Almost done with the initial version of "followalong" a site/extension that allows for collaborative browsing (and triaging)
    • makes sure everybody has a full list of what's being triaged
    • ensures confidentiality of bugs/links
    • allows anyone to drop in and join in triaging at any time
  • Changes to bugzilla planned which enforce data collection when requesting tracking/approval (user impact, reproducibility, testing completed, etc.)
  • Have a tool planned to help automate the process of marking bugs and creating rollups