linaro-project-management team mailing list archive

[Deepak Saxena <dsaxena@xxxxxxxxxx>]

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

Attachment: kernel_roadmap_merge_window_based.png
Description: PNG image