linaro-project-management team mailing list archive

[Michael Hope <michael.hope@xxxxxxxxxx>]

Hi there PM'ers.  What are your thoughts on blueprints, milestones,
and upstream interaction?  A new toolchain feature goes through the
following states:

 1. Implementation
 2. Upstream discussion
 3. Upstream review
 4. Upstream acceptance
 5. Commit upstream
 6. Shake down
 7. Backport to gcc-linaro
 8. Release in gcc-linaro

(2) and (3) make take weeks.  (4) can be terrible and take a month.
(6) is an optional week or so where we see if any issues are found
with the patch.

Because of this upstream interaction, a developer can't complete one
blueprint before moving onto the next, can't reliably estimate when a
feature will be available in gcc-linaro, can't complete a blueprint in
a month, and may have three or four blueprints in flight at any one
time.

My plan is:
 1. When a developer comes free, they pick the next best blueprint
 2. They assign it to themselves, remove the 'backlog' milestone, and
mark it as 'Started'
 3. If the work gets stuck in review or acceptance due to no response
then they mark it as 'Blocked'
 4. Once the work has been accepted, they mark the blueprint against
the next milestone
 5. They backport in a timely way
 6. Once backported, they mark it as as 'Deployment'
 7. On release, I change all 'Deployment' blueprints to 'Implemented'

There are other cases where upstream rejects a feature or the extra
work is more than can be justified, but I'm not worried about those.
They happen now and again with performance work where you think
something is a good idea but it turns out otherwise.

Thoughts?

-- Michael