linaro-project-management team mailing list archive

[Amit Kucheria <amit.kucheria@xxxxxxxxxx>]

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.

/Amit