Monthly Implementation

draft r0b

Changes:

  • Explained that new aspects may be found while implementing and preempt the current blueprint
  • Backlog is now tracked via milestone == backlog
  • Smaller blueprints are now used instead of work item blocks
  • Added a state transition diagram showing overlap
  • Contentious things are in bold

Linaro is discussing switching from a six monthly planning cycle to monthly with a back log. This page describes how the toolchain group will implement this.

General approach:

  • we start from stable, released products and add many small improvements
  • a blueprint covers a self contained chunk of work that contributes to a feature
  • one person is responsible for a blueprint
  • blueprints can be finished
  • a blueprint is finished before moving onto the next
  • assignees pick the next blueprint from the group-wide pool of blueprints

Half of our blueprints are like this. New blueprints may be spawned based on investigation or through discovering other aspects while implementing a feature. A new aspect may be put into the backlog or, if it blocks the current blueprint, be switched to immediately. A developer may have many blocked blueprints that are stuck on upstream response.

We work upstream and backport to gcc-linaro to make features available early. A feature goes through the following steps:

  1. Investigation
  2. Implementation against upstream
  3. Upstream review
  4. Upstream approval
  5. Upstream commit
  6. Backport

Upstream review and approval are unpredictable. Iteration may be needed during review. Features may be rejected by upstream and the work discarded.

Releases are:

  • made on the third Thursday from end of the month
  • started on the Monday
  • named product-series-yyyy.mm[-respin] such as gcc-linaro-4.5-2011.06 for the first release and gcc-linaro-4.5-2011.06-1 for the first respin
  • released on Launchpad
  • announced on Launchpad, linaro-announce, and linaro-toolchain

The branch is 'frozen' from Monday to Thursday, but this has little effect as work is done on feature branches.

Platform:

  • pick up the monthly toolchain releases
  • release on the last Thursday of each month
  • will work around toolchain faults if feasible
  • will work with toolchain to fix and respin otherwise

Planning:

  • we run a backlog. Currently the backlog is around six months of work
  • on the Monday after each release, assignees will pick the blueprints to start during the next month

  • the list will be conservative
  • predictable blueprints will be targeted to the milestone
  • blueprints with external dependencies will be targeted to the milestone once those dependencies are cleared

  • work may be pulled in from the backlog as the month goes by
  • work items are no more than a week long
  • an assignee should check off one or more work items a week

As we gain experience, our estimation should get better and less conservative. External dependencies include upstream and IS.

Issues:

  • depending on the month, the platform release is one or two weeks after the toolchain release. One of the dates should change to make it consistent month-to-month
  • a toolchain month starts half way through a calendar month

Visualisation

Assume a Kanban model. Toolchain's categories are:

  • Wishlist - things that we want to record and not lose but have no plans to work on
  • Backlog - approved but not assigned to anyone
  • Todo - approved and assigned, but not yet started
  • In progress - approved, assigned, and started
  • Blocked - approved, assigned, mostly done but stuck on something external like upstreaming
  • Done - approved, assigned, complete, and upstream

or, in table form:

Priority == Not?

Milestone == backlog?

Assigned?

Implementation like Started?

Implementation == Blocked?

Implementation == Implemented?

Wishlist

Y

N

*

*

*

*

Backlog

*

Y

*

*

*

*

Todo

N

N

Y

N

N

N

In progress

N

N

Y

Y

N

N

Blocked

N

N

Y

N

Y

N

Done

N

N

Y

N

N

Y

Note that wishlist is a bit of a hack.

See also Michael's prototype.

Mechanics

There are a number of Thumb-2 performance blueprints in the backlog, including:

  • Improve constant generation in Thumb2
  • Reduce the amount of redundant moves from VFP to ARM Core registers
  • Investigate current constant pool generation / placement
  • Backport A15 div instruction support from mainline
  • Backport A5 tuning of BRANCH_COST
  • Backport any interesting A15 tuning from mainline
  • Investigate the register allocator

At the start of the monthly cycle, Andy decides that he can definatly implement the first three in a month. The third is contentious and will involve significant discussion upstream. This is unpredictable so he can't gaurantee that it will be backported by the end of the month.

At the start of the month he:

  • assigns himself to all three.
  • changes the milestone from 'backlog' to '4.6-2011.09' for the first two
  • clears the milestone on the last.

He updates the status each week.

He begins work on the first blueprint and:

  • sets the Implementation field to 'Started'
  • does the work against trunk
  • discusses it upstream
  • has it accepted
  • backports it to gcc-linaro

The work is now completed so he marks it as 'Implemented'.

He begins work on the second blueprint and:

  • sets the Implementation field to 'Started'
  • does the work against trunk
  • discusses it upstream
  • waits for approval

The upstream maintainer is reasonably responsive and the developer expects a response within a week. He leaves the blueprint as 'Started'.

He moves on to the third blueprint while waiting and:

  • sets the Implementation field to 'Started'
  • prototypes an implementation
  • discusses it upstream
  • keeps on discussing
  • gets stuck due to a lack of feedback

The work is stuck on upstream discussion so he marks it as 'Blocked'

Over the month, the features change state as follows:

Feature 1

Feature 2

Feature 3

Backlog

Backlog

Backlog

Todo

Todo

Todo

In progress

Todo

Todo

Done

Todo

Todo

Done

In progress

Todo

Done

In progress

In progress

Done

In progress

Blocked

Done

Done

Blocked

Note that Feature 2 and Feature 3 overlap.

WorkingGroups/ToolChain/Style/MonthlyImplementation (last modified 2012-12-04 23:10:14)