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