linaro-project-management team mailing list archive

[Deepak Saxena <dsaxena@xxxxxxxxxx>]

On 5 March 2012 03:10, Amit Kucheria <amit.kucheria@xxxxxxxxxx> wrote:
> On Sat, Mar 3, 2012 at 2:20 AM, John Stultz <john.stultz@xxxxxxxxxx> wrote:
>> On Fri, 2012-03-02 at 15:35 -0800, Deepak Saxena wrote:
>>> I'm not sure that I'm properly explaining this as I am still
>>> formulating, I'm attaching a visual representation. In this case, we
>>> have a feature X that has several sub-features that we think can go
>>> upstream during different cycles. At the end of each merge window, we
>>> revisit the status of a project and make adjustments to our schedule
>>> based on how the process is going with upstream. If we find that a
>>> given sub-feature is dangerously slipping or not being accepted
>>> upstream, we can ensure the TSC knows as it is happening and course
>>> correct as needed.
>>>
>>> The main advantage I see of shifting to this approach is that kernel
>>> developers work flow is naturally aligned against Linus' merge and
>>> release window, not against monthly milestones or roadmap quarters. I
>>> also think that it would give more visibility to the TSC into the
>>> process vs what we're doing now.
>>
>> Just a small comment on your drawing...
>>
>> I suspect it will be difficult to accurately plan/estimate more then two
>> releases out, mainly due to what I'll call the "eternal optimism of
>> development" (It will all be done next interval! - for some limited
>> definition of "all").
>>
>> So instead of having items that need to be done, or are likely to slip
>> two windows out as you have at the "End of 3.4 merge window" figure, I
>> suspect at the end of the 3.4 merge window you'll have:
>> 3.4:
>>        Initial discussion [Done]
>> 3.5:
>>        Sub-feature A [in-progress]
>>        Sub-feature B [in-progress]
>>        Sub-feature C [in-progress]
>>
>> Then as the merge window for 3.5 approaches it will turn into
>>
>> 3.5:
>>        Sub-feature A [queued for merging at 3.5]
>>        Sub-feature B [NACKED]
>>        Sub-feature C [in-progress, at risk]
>> 3.6
>>        Sub-feature B' [in discussion]
>>        Sub-feature D [in-progress]
>> 3.7
>>        Sub-feature E [in discussion - will depend on D]
>>
>> Then at the end of the 3.5 merge window you'll probably see:
>> 3.5
>>        Sub-feature A [MERGED]
>>        Sub-feature B [NACKED]
>> 3.6
>>        Sub-feature C [almost done, queued for 3.6 soon]
>>        Sub-feature B' [in-progress]
>>        Sub-feature D [in-progress]
>>        Sub-feature F [in discussion, will likely slip]
>>        Sub-feature G [in discussion, will likely slip]
>> 3.7
>>        Sub-feature E [in-progress - depends on D]
>>
>>
>> But overall, I think the idea is a good one. I think its much easier for
>> developers to accurately provide confidence rankings of features being
>> merged in the current or next merge window. This will likely better
>> communicate development status and planning, rather then the monthly
>> breakdowns which are hard to target, since they may or may not line up
>> with kernel releases, and if something slips a kernel merge window, it
>> won't necessarily be "done" the following month (instead its likely to
>> be done after the next merge window).
>>
>>
>> I think it might also be useful to track the phases of development as:
>> * Discussion
>> * Development iteration N
>> * Queued for release X.Y
>> * Merged X.Y
>>
>> That way there's better visibility into how the development is
>> progressing vs being stalled out. As often it takes many many
>> iterations, which can sometimes appear to outsiders as not much being
>> accomplished. The iteration delta would provide some sense of velocity.
>>
>> Further, once something is queued, there may not be any news on it for a
>> few months until the next merge window opens.
>>
>> thanks
>> -john
>>
>
> Deepak, John,
>
> This looks good! This will work out nicely for us in PMWG as well.
>
> And John's elaboration on some of the nuances should be documented for
> those that aren't familiar with how kernel development works. I've
> been hard-pressed to make several people understand that 'design',
> 'implement' and 'upstream' blueprints for a feature don't work for us.

+1. I'm working on a write up for our members report for that explains this.