On Sat, Mar 3, 2012 at 1:20 AM, John Stultz <[email protected]> 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 > How can a developer provide more accurate info on something he doesn't know the date for? Doesn't that mean that developers just makes an easy, underambitious guess? Don't want to say I don't like it and I strongly agree that we should have kernel features associated with a target merge window. I just think not aligning the discussion and development iterations to a fixed delivery date will cause folks to loose track of things and it will be hard for PMs/RMs to help you that this won't happen. 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 > In general what you propose is a good way to tracking phases of a kernel feature from discussion to merging. Now the question is if and how this can be aligned with Linaro's heartbeat... I think you say it can't be? My high level feel is that I don't see though why everything except the merged x.y cannot be aligned with our all-linaro-monthly heartbeat. For instance you decide you want to work on problem Z. Discussion and the development iterations will be aligned with Linaros monthly cycle (why not?). Discussion wraps up with a nice summary/blog-post etc. and the development iterations go into a topic branch that we track and provide as a solution. > 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. > > As long as you say that each iteration will be provided as a topic that we validate in our linux-linaro tree I agree with what you say ... :). Having time based milestones to release topics work-in-progress topics or make a nice summary will help outsiders to understand the pace. On top I see the phases you describe as a good way to present the high level state of a currently developed kernel feature. I think with a reasonable amount of effort we can work such visualization into our tools. For instance we could add a meta field which phase a blueprint is for etc. And yes, since most work we do in Linaro is kernel work, we definitely should do that. Let's work on that with danilo/mattias and andrey. On the monthly vs. upstream window plan I still believe that steps that are in our hand can still be aligned with monthly. Key of developing a kernel feature is not the ultimate landing, but the development iterations, because once they are done you just "stage" them for merging into the next window, do you agree? The problem with saying we align to upstream only is that we have no information about when the next merge window will be. Stuff that we don't know the date for (merge window), could be somehow targetted against a non-dated milestone. We need to set up mechanisms for PMs/RMs to ensure they can track those windows easily to not accidentally slip. -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
_______________________________________________ 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
