On 5 March 2012 03:10, Amit Kucheria <[email protected]> wrote: > On Sat, Mar 3, 2012 at 2: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 >> 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. _______________________________________________ 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
