linaro-project-management team mailing list archive

[John Stultz <john.stultz@xxxxxxxxxx>]

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