Release Management/Goals/2013Q3
From MozillaWiki
< Release Management | Goals
General Engineering
- Become more involved in the community
- [ON TRACK] Each RM should write at least 3 blog (or dev.planning) posts explaining/proposing RM processes and improvements
- [akeybl] 1.2 and On Release Model, Rethinking Aurora, and Team Structure
- [DONE] [bajaj] Mozsummit, stability work week(have notes already), and Nag tool wiki
- [lsblakk] Tracking Efficacy & Rapid Beta Early Feedback, ?, and ?
- [preeti] Current issues with B2G, How is Release Management at Mozilla different from Juniper Networks
- [DONE] Prepare a Summit presentation with a similar focus to the above blog posts
- [all]
- [ON TRACK] Each RM should write at least 3 blog (or dev.planning) posts explaining/proposing RM processes and improvements
- Continue our tools & automation work
- [ON TRACK] Round 2 of the release dashboard (continued from Q2 2013)
- [lsblakk] v0.1: getting the dashboard ready for RelMan dogfooding in early Q3 (very close to being done)
- [lsblakk] v0.2: improvements to allow for use by wider audience (managers, devs) - public 'release' but still on staging env at first
- Can choose which 'shared' queries to include in a custom view
- On sign up you get a custom view default per org chart
- [ON TRACK] Round 2 of the merge day script - single push button (continued from Q2 2013)
- [bajaj] As a first checkpoint I wish to to have all the hg commits/tags/out be integrated in existing merge_help.py
- The above is on-track and I tested my script in the last central->aurora merge, I did run into a few conflicts, I am cleaning up the script to accommodate those and should be finishing it up by Friday(8/9) and emailing you guys for review
- [DONE] Automate the update of product-details [lsblakk]
- [ON TRACK] Round 2 of the release dashboard (continued from Q2 2013)
Firefox Desktop/Mobile
- Re-focus RM efforts on mozilla-central
- [AT RISK] Involve integrators in the enforcement of good development practice, and possibly other tasks (such as daily changeset notes)
- [?]
- [DONE] Place an "advertisement" for a Community Release Manager focusing on Nightly noms and tracked bugs, and begin interviews
- [bajaj, lsblakk]
- [AT RISK] Involve integrators in the enforcement of good development practice, and possibly other tasks (such as daily changeset notes)
Firefox OS
- Get even more involved with the details of B2G
- [DONE] Participate in driving daily B2G smoketest blockers, ensuring a timely backout of the regressing bug
- [akeybl, all]
- [DONE] Participate in driving daily B2G smoketest blockers, ensuring a timely backout of the regressing bug
- Get rid of new B2G partner confusion around triage
- [DONE] Enable TAMs to quickly bring a partner into the triage loop, as much through documentation as possible
- [bajaj] coordinate TAM meeting -- done
- [akeybl] create outline of blocking/non-blocing issues
- [ON TRACK] Refine/document the process of how each partner can block a specific bug (continued from Q2 2013)
- [Preeti]
- [DONE] Create a set of rules, expectations, and separation of responsibility for triage
- [Preeti] see https://wiki.mozilla.org/FirefoxOS/OneDotTwoTracking
- [DONE] Enable TAMs to quickly bring a partner into the triage loop, as much through documentation as possible
- Create external pre-release populations for B2G
- [DONE] Meet with GP to improve quality and frequency of builds, and coordinate feedback from their customers (OEM pre-release program)
- [akeybl]
- [AT RISK] Use the reference hardware for v1.2 to build to build a pre-release population (Mozilla pre-release program)
- [akeybl] at risk due to delay in acquisition of reference hardware
- [DONE] Meet with GP to improve quality and frequency of builds, and coordinate feedback from their customers (OEM pre-release program)