linaro-project-management team mailing list archive

[Michael Hope <michael.hope@xxxxxxxxxx>]

On Wed, Aug 24, 2011 at 3: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.

Agreed.  I'd prefer to change the status to 'Blocked'.

> And besides, don't you want engineers to want to get better at
> predicting when their work will be accepted? I get the argument that
> upstreaming code is hard to predict, but it is definitely not /totally/
> chaotic and unpredictable -- if the patch concept 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.

GCC isn't predictable.  You might have a patch that touches three
areas and needs approval from three different maintainers.  The third
may be unresponsive.  ARM backend approval is poor.

QEMU is similar - the main approver does this after hours and can take
weeks before flushing the backlog.

I've set a policy for pinging patches, but that only makes the
frustration regular, not the approval :)

-- Michael