linaro-project-management team mailing list archive

[Michael Hope <michael.hope@xxxxxxxxxx>]

(mild replying to self)

I've updated my plan:
 https://wiki.linaro.org/MichaelHope/Sandbox/MonthlyImplementation

based on the backlog discussion in another thread.  I've bolded
(emboldened?) the contentious parts which are:
 * on the Monday after each release, assignees will pick the
blueprints to *start* during the next month
 * blueprints with external dependencies will be targeted to the
milestone *once those dependencies are cleared*

This is to cover upstream being unpredictable.

-- Michael

On Mon, Aug 22, 2011 at 11:10 AM, Michael Hope <michael.hope@xxxxxxxxxx> wrote:
> 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
>