Release Management/Goals/2013Q3: Difference between revisions

From MozillaWiki
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}}
** {{ok|Prepare a Summit presentation with a similar focus to the above blog posts}}
*** [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])}}
** {{ok|Automate the update of product-details}}
*** [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'''
** {{ok|Involve integrators in the enforcement of good development practice, and possibly other tasks (such as daily changeset notes)}}
** {{risk|Involve integrators in the enforcement of good development practice, and possibly other tasks (such as daily changeset notes)}}
** {{ok|Place an "advertisement" for a Community Release Manager, focusing on Nightly noms and tracked bugs}}
*** [?]
** {{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'''
** {{ok|Participate in driving daily B2G smoketest blockers, ensuring a timely backout of the regressing bug}}
** {{done|Participate in driving daily B2G smoketest blockers, ensuring a timely backout of the regressing bug}}
** {{ok|Ensure that at least one RM is testing each day's B2G build, filing bugs as necessary}}
*** [akeybl, all]
* '''Get rid of new B2G partner confusion around triage'''
* '''Get rid of new B2G partner confusion around triage'''
** {{ok|Enable TAMs to quickly bring a partner into the triage loop, as much through documentation as possible}}
** {{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])}}
** {{ok|Create a set of rules, expectations, and separation of responsibility for triage}}
*** [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'''
** {{ok|Meet with GP to improve quality and frequency of builds, and coordinate feedback from their customers (OEM pre-release program)}}
** {{done|Meet with GP to improve quality and frequency of builds, and coordinate feedback from their customers (OEM pre-release program)}}
** {{ok|Use the reference hardware for v1.2 to build to build a pre-release population (Mozilla 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
  • 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]

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]

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]
  • 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
  • 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