linaro-project-management team mailing list archive

[Alexander Sack <asac@xxxxxxxxxx>]

On Sat, Mar 3, 2012 at 1:20 AM, 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").
>
> 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