On Wed, Aug 24, 2011 at 3:41 AM, Christian Robottom Reis <[email protected]> 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 _______________________________________________ Mailing list: https://launchpad.net/~linaro-project-management Post to : [email protected] Unsubscribe : https://launchpad.net/~linaro-project-management More help : https://help.launchpad.net/ListHelp
