linaro-project-management team mailing list archive

[Deepak Saxena <dsaxena@xxxxxxxxxx>]

On 5 March 2012 03:08, Alexander Sack <asac@xxxxxxxxxx> wrote:
> 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.

We don't track releases, we track work being done. The merge/release windows
provide a not quite solid but somewhat bounded target date to focus towards.
So while I can't say, "we'll be done on this date", I can say "we're targeting
around this timeframe as we expect a merge window at this point". (Note that
sub-maintainer merge windows are out of phase of Linus' merge window).
The goal of every kernel developer working actively with the community
is to get
their upstream, so while we're not thinking of meeting date-based deadlines,
we do actively pay attention to the upstream development cycle and work in
sync with that cycle to get our code into maintainer  trees. It's not
a free for all
as many people seem to think of, it just doesn't fit the design -> code -> test
-> release model.

>> 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.

My thought on this is that  I don't want engineers to have to think
about two different
cycles. Their focus and goal should be getting code upstream and they can make
their code available for being pulled into the monthly Linaro releases as is w/o
worry of "productizing" the code for a Linaro release that does not align with
an upstream release. Meaning, if it's broke at that point in time, we
just don't
pull it into the release and fix the issue in the timeframe that works
best taking
into account other upstream cycle considerations. For example, if fixing
sub-feature X on platform A in the time frame for a monthly release interferes
with some  really important discussion and work that needs to be done
for that sub-feature along with sub-feature Y, I want the engineer to focus
on the later.

>> 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.

See above. :) I think more of  human-readable status page too, not just the BP
or the status.linaro.org page, would be useful to external partie.

> 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?

Mostly, but there's a window there where another change could come in...

> 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.

I understand the perspective, I think we just need to retrain ourselves from
thinking of solid dates to approximate merge window dates based on educated
guesses.

~Deepak