linaro-project-management team mailing list archive

[Ricardo Salveti <ricardo.salveti@xxxxxxxxxx>]

On Wed, Mar 7, 2012 at 10:38 PM, Deepak Saxena <dsaxena@xxxxxxxxxx> wrote:
> On 5 March 2012 03:08, Alexander Sack <asac@xxxxxxxxxx> wrote:
>> 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 you can easily track the work and iterations if you assume
that your milestones are the upstream kernel releases. This
information about the current development (discussions, progress,
review) is something that will be produced anyway, it's just that the
PM needs to adapt to the process.

But, for that we'd need to change the process a bit and adapt the
current way of planning/developing/deploying the features.

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

I tend to agree with Deepak here, and it seems better for the
developers to only track and worry about one single progress, and a
process that they would need to know anyway (the upstream way of
working).

I believe here is something that we can manage better if we also agree
that as part of the development, the tracking branch (development
tree, whatever), will also be integrated at linux-linaro, and that is
the tree that will be released and used during our monthly releases.
Creating the pull requests for linux-linaro, and working together at
least to make sure things are working properly (as the tree will be
tested, and specific tests can also be done against the specific
feature that is on development), should probably be enough already.
Then Andrey and the platform team can follow and create the releases
for it.

This will only work if we make the process flexible enough that we
don't strictly force the engineers to spend time fixing the branches
for a release. It should work in a way that if the branch is broken,
or causing issues, it should basically be dropped and re-worked in the
next monthly cycle. If we use the linux-linaro tree as a way to test
and validate the development, I don't think the engineers will
complain about the process.

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

I don't think that aligning with upstream would be a problem, we just
need to adapt ourselves to the process, instead of trying to change
it. Generally we don't want to plan features that will be
delivered/integrated in more than 3 kernel releases ahead the current
one, so we should be fine.

Cheers,
-- 
Ricardo Salveti de Araujo