linaro-project-management team mailing list archive

[David Rusling <david.rusling@xxxxxxxxxx>]

Deepak,
  I like this (and it fits with some of Roger's thoughts).   You could also tag and track some of the kernel releases with those that are expected to be used in Android.

Dave

Sent from yet another ARM powered mobile device

On 2 Mar 2012, at 23:35, Deepak Saxena <dsaxena@xxxxxxxxxx> wrote:

> So there's been a few threads going around about how do we do a better
> job delivering kernel related work vs our roadmap cards and how do we
> incorporate the upstream process into our deliverables and after
> chatting with John yesterday, I've got a proposal for slightly
> changing our approach on how we map out kernel work. Instead of a date
> based roadmap, which doesn't work with the reality of not having any
> control on kernel release dates, I propose we track our deliverables
> against kernel merge windows and break roadmap items into smaller
> chunks that across multiple windows. The first merge window may simply
> be a discussion phase, but as we figure out the details of a problem,
> we can start coming up with an educated guess about what merge window
> specific portions of the work might be accepted upstream. As we
> continue to work and we have to shift focus, we can just move small
> deliverables around instead of slipping a whole roadmap card.
> 
> 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.
> 
> Thoughts?
> ~Deepak
> <kernel_roadmap_merge_window_based.png>