linaro-project-management team mailing list archive

[Michael Hope <michael.hope@xxxxxxxxxx>]

On Tue, Aug 23, 2011 at 11:01 AM, Joey Stanford <joey@xxxxxxxxxx> wrote:
>> 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?
>
> Hmm, you've found... a loophole. :-)
>
> I need some time to reflect on this but off the cuff I can see three options:
>
> 1) Keep moving the BP or don't commit to a milestone until it's
> upstreamed.  I don't like this option at all.
> 2) Once we send something upstream we can put the BP into "deployment"
> status and leave it on the milestone. Once upstream accepts the code
> then we could change it.  I'm not sure I like this either. I feel like
> we're hiding the upstream work.
> 3) Once we send something upstream we put the BP into "implemented"
> status and move the upstreaming action somewhere else. (i.e. we don't
> block completion of a BP on upstreaming)   This feels to me like a
> more natural fit for how we're organized but I don't have a solution
> for how to track upstreaming and ensure we are constantly looking at
> it (beyond patchwork that is).

Yip, that's along the line of my method.  To make things more
interesting, we don't backport features until they're upstream.

My plan was:
 * Pick a blueprint
 * Assign yourself
 * Remove the 'backlog' milestone
 * Work on it
 * Send it upstream
 * Mark the status as 'Blocked'
 * Get approval
 * Mark the status as 'In progress'
 * Assign to the next monthly milestone (as it's now back under our control)
 * Backport, release, close out the blueprint

So:
 * If milestone == backlog, then it's work to be done
 * If milestone == None and assigned, then it's in progress
 * If milestone == None and status == Blocked, then it's pretty much
done but blocked on upstream
 * If milestone == monthly then it's almost there

-- Michael