Jump to: navigation, search

Release Management/Liberty Tracking

Revision as of 10:52, 20 February 2015 by ThierryCarrez (talk | contribs) (Created page with "== How release tracking worked in Kilo == In Kilo and previous releases, release tracking was a double mission: ==== Communicate what is likely going to land in the cycle by...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

How release tracking worked in Kilo

In Kilo and previous releases, release tracking was a double mission:

Communicate what is likely going to land in the cycle by maintaining our best attempt at a prediction

This was done by constantly refining the list of blueprints that are likely to land for each milestone. This is the work of release liaisons for each project, work that is reviewed almost every week during the 1:1 syncs.

Produce release pages that list the key features (and bugfixes) that were added during a given development milestone and cycle

On the bugfixes side, this was done using automated scripts that take FixCommitted Launchpad bugs and target them to the milestone they were fixed in. On the features side, this was done by taking the milestone objectives list, trusting that all completed work was actually targeted, and deferring incomplete work to the next milestone.


Problems we are trying to solve

  • Current Release tracking takes a lot of time (3 hours per week) and doesn't scale
  • Most of the time (80%) is spent achieving the first part of the mission
  • The prediction we communicate is extremely unreliable
  • Nobody actually seems to consume the prediction we communicate
  • Product managers are actually more interested in seeing the list of things being worked on, and then the list of things that were actually implemented.


Proposed Liberty release tracking

The proposed change is to stop using Launchpad milestone pages before a milestone is actually completed (i.e. stop trying to predict). Release liaisons may use Launchpad series page instead, as a way to conveniently track release cycle main goals. The release status page would be reworked to communicate the completed work and the status of the in-progress work (without necessarily promising when it shall land).

Move away from per-milestone predicting to giving a general completion status of features being worked on

  • Assignees should maintain the status of their blueprint (in particular, set it to "Started" when started and to "Implemented" when completed)
  • Release liaison may opt to track their specific cycle goals by setting the series goal (not mandatory)
  • Assignees may target their blueprint to a future milestone, as an indication of when they intend to land it (not mandatory)
  • Stop running the autokick script to guard milestone pages and align series goal and milestone targets
  • Reorganize release status page to show past milestones completed blueprints first, then series-targeted blueprints (then, maybe, other started stuff)


Continue to produce release pages

  • On milestone tags, automatically remove the milestone target from incomplete bugfixes and blueprints (or defer to next milestone ?)
  • Automatically pick up recently-FixCommitted bugfixes and add the milestone target to them (as usual)
  • Automatically pick up recently-Implemented blueprints and add the milestone target to them
  • Release liaisons should make sure we don't miss a key feature (and retroactively file an implemented blueprint if that's the case)