linaro-project-management team mailing list archive

[Deepak Saxena <dsaxena@xxxxxxxxxx>]

On 2 March 2012 16:20, 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").

Heh, I tend to think of myself as an eternal pessimist..."it'll be done
when it's done":)

> 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]

This make sense to me. Committing beyond 2 merge windows is already
possibly 6 months out and up for a lot of change given all the people
involved outside of our control so anything beyond that we're just
throwing darts blindly.

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

The question I have is at what granularity do we track this, i.e,
does a sub-feature == a patchset?

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

Yes, and in that case we need to keep the tracking, whether in a blueprint
or on the wiki as "open" until we see it one of Linus' releases. Depending on
the feature and how it interacts with other parts of the kernel, there's also
the risk that as it makes its way up the maintainer hierarchy, we'll end up with
some bug due to other code that may (miss-)interact with the feature we
care about. This is also why unit testing and validation are important parts of
the process that we need to further integrate into our development cycles.

~Deepak