linaro-project-management team mailing list archive

[Christian Robottom Reis <kiko@xxxxxxxxxx>]

On Mon, Aug 22, 2011 at 05:01:19PM -0600, Joey Stanford wrote:
> 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.

I think the blueprint /most/ move miletones if it wasn't delivered (i.e.
pass its acceptance criteria) in that month. Therein there is a hint on
a way we could solve this: by splitting the work up sensibly. And I
don't mean "Blueprint 1: Implement", "Blueprint 2: Upstream", but
starting with something like:

    - Build internal prototype (1 week)
    - Prototype shared with upstream for review (1 week)
    - Plan next steps (?)

which then folds out into:

    - Build internal prototype (1 week)
    - Prototype shared with upstream for review (1 week)
    - Address first loop of design issues
        [times N where N is related to the complexity of the change's
        impect]
    - Land first piece of implementation upstream
        Celebrate

I don't think the prototype and share upstream phases should take more
than 2 weeks combined. So if you want to split a blueprint up on those
lines, you have a safe bet of having delivered something and then having
a plan for future work.

I don't think /any/ upstream-bound work should start without a prototype
to be shared upstream.

> 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).

I don't feel this is sane. You can't say "implemented" when something is
sent upstream -- the very first reply can be a NAK. See the recent case
of a hotplug submission to which this happened.
-- 
Christian Robottom Reis, Engineering VP
Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935
Linaro.org: Open Source Software for ARM SoCs