Release Management/Goals/2013Q3: Difference between revisions
< Release Management | Goals
Jump to navigation
Jump to search
No edit summary |
|||
(28 intermediate revisions by 4 users not shown) | |||
Line 2: | Line 2: | ||
* '''Become more involved in the community''' | * '''Become more involved in the community''' | ||
** {{ok|Each RM should write at least 3 blog (or dev.planning) posts explaining/proposing RM processes and improvements}} | ** {{ok|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 }} | |||
**** http://bhavanabajaj.wordpress.com/2013/10/31/mozsummit-2013-one-helluva-experience/ | |||
**** http://bhavanabajaj.wordpress.com/2013/10/15/mozilla-stability-workweek-2013/ | |||
**** https://wiki.mozilla.org/User:Bhavana/Nag_Tool | |||
*** [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] | |||
* ''' Continue our tools & automation work''' | * ''' Continue our tools & automation work''' | ||
** {{ok|Round 2 of the release dashboard (continued from [https://wiki.mozilla.org/Release_Management/Goals/2013Q2 Q2 2013])}} | ** {{ok|Round 2 of the release dashboard (continued from [https://wiki.mozilla.org/Release_Management/Goals/2013Q2 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 | |||
** {{ok|Round 2 of the merge day script - single push button (continued from [https://wiki.mozilla.org/Release_Management/Goals/2013Q2 Q2 2013])}} | ** {{ok|Round 2 of the merge day script - single push button (continued from [https://wiki.mozilla.org/Release_Management/Goals/2013Q2 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] | |||
=== Firefox Desktop/Mobile === | === Firefox Desktop/Mobile === | ||
* '''Re-focus RM efforts on mozilla-central''' | * '''Re-focus RM efforts on mozilla-central''' | ||
** {{ | ** {{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] | |||
=== Firefox OS === | === Firefox OS === | ||
* '''Get even more involved with the details of B2G''' | * '''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] | ||
* '''Get rid of new B2G partner confusion around triage''' | * '''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 | |||
** {{ok|Refine/document the process of how each partner can block a specific bug (continued from [https://wiki.mozilla.org/Release_Management/Goals/2013Q2 Q2 2013])}} | ** {{ok|Refine/document the process of how each partner can block a specific bug (continued from [https://wiki.mozilla.org/Release_Management/Goals/2013Q2 Q2 2013])}} | ||
** {{ | *** [Preeti] | ||
** {{done|Create a set of rules, expectations, and separation of responsibility for triage}} | |||
*** [Preeti] see https://wiki.mozilla.org/FirefoxOS/OneDotTwoTracking | |||
* '''Create external pre-release populations for B2G''' | * '''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] | ||
** {{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 |
Latest revision as of 05:42, 31 October 2013
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)