← Back to team overview

linaro-project-management team mailing list archive

Re: Upstream and planning

 

On Tue, Aug 23, 2011 at 10:41 AM, Christian Robottom Reis
<kiko@xxxxxxxxxx>wrote:

> On Tue, Aug 23, 2011 at 10:07:04AM -0500, Mounir Bsaibes wrote:
> > > So my question stands: we don't control upstream and can't assign a
> > > blueprint to a monthly milestone as we don't have control over when it
> > > will actually land.  How should this be handled?
> >
> > Should we have another milestone called 'Upstream' for example? (This
> > milestone would be a place holder milestone similar to the 'Backlog'
> > milestone)
>
> Conceptually, I think this is a bit bogus. Backlog is an accurate
> indication of the scheduling of an unstarted blueprint or bug (i.e. its
> milestone is unknown), whereas a task which is already being worked on
> has context around it, which would be lost if you just retargeted the
> task to upstream.
>
> And besides, don't you want engineers to want to get better at
> predicting when their work will be accepted?

 yes - absolutely.

> I get the argument that
> upstreaming code is hard to predict, but it is definitely not /totally/
> chaotic and unpredictable -- if the patch concpt is sane then it's a
> number of interations and then hitting a merge window. There's something
> of a rhythm to it. It shouldn't take multiple months for most patches to
> be accepted, and epic patches (see CMA) should be specially planned for.
>

An alternative flow can be as follows:
1. When a developer comes free, they pick the next best blueprint
 2. They assign it to themselves, remove the 'backlog' milestone, *target
it  to a milestone based on an educated guess and learned experience**,* 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' *and target it to Upstream milestone *(at
this time, we don't know when it will be accepted).
 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'

> --
> Christian Robottom Reis, Engineering VP
> Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935
> Linaro.org: Open Source Software for ARM SoCs
>



-- 
Mounir Bsaibes
Project Manager

Follow Linaro.org:
facebook.com/pages/Linaro/155974581091106
http://twitter.com/#!/linaroorg
http://www.linaro.org/linaro-blog <http://www.linaro.org/linaro-blog>

Follow ups

References