linaro-project-management team mailing list archive

[Joey Stanford <joey@xxxxxxxxxx>]

Howdy,

I've made some updates to the presentation today.  Some comments here:

> 4/33: will the linaro overall cycle be maintained? What will be the
> relation with the Ubuntu cycle? Also the dates for the last two releases
> are too close? That is bound to increase the workload since just after
> finishing the october release, the november release will happen + planning.

Monthly only. Ubuntu will be pulled in when it's released.

> 6/33: Component Milestone models: not all components need 2 or even 1 wk
> of freeze. As such there is a dependency on top of other components, eg
> the toolchain. There should be some slide showing the dependencies for
> the cycle

Right now it's up to the WG/Team to determine which of the two models
they want to use.  For depedencies, this also needs to be done in each
group because no single person has this level of details.  It goes
beyond what you mentioned too: a particular group may be dependent
upon a BP or WI from another team.  This is going to be sticky but
it's what is happening now.

> 8/33: sentence "target those against milestones and not arbitrary work
> items => smart work item scheduling" - I have a feeling of what you are
> trying to say however the sentence can be confusing.

asac is going to reword

> 10/33: can we get rid of having 3 types of blueprints? At most 2 types
> would be enough, the TR can serve also for collecting comments that are
> used in the blueprints which analyze the stories into work items.

We did already. Just two. TR and Engineering BP. Andy sent an email
around after UDS.

> 14/32:  proposal: since we are accelerating cadence we ought to observe
> a decrease on batch sizes per queue per team. Can we get some flow
> diagrams in s.l.o eg cumulative flow diagram of the queue size per team,
> to see other opportunities for improvement? With historical data we
> could also show trends per team in order to spot possible flow problems.
> Also how about measuring the aging on queues?

Yes, great idea. How?

> 21/32: we should also measure efficiency in queue handling, eg size of
> queue, trends on size, aging of items in the queue as well as feedback
> speed (how long from blueprint getting created to getting approved to
> getting done) and overall aging of problems

Could do. How?

> Some more received comments :
> - draw a couple of flow diagrams against a time line to show the monthly
> cadence (ideally with the inter dependencies marked) as well as the
> events during the quarters and year

I tried to do that yesterday but apparently I can't drawn. I'm not
Jamie. :-)  I can do tables though.  We'll be creating a wiki page
with something in the future. I've assigned that to Andy.

> - it would help putting the new cadence in perspective with ubuntu cycle
> cadence since many have had that as a ruler when planning

I'll leave this for Fathi to determine if it's worth expending the effort.

J