Linux kenrel: Moving to a 4.17 base

[Joel Stanley]

Hello Tao,

On 30 May 2018 at 17:57, Tao Ren <taoren at fb.com> wrote:
> This is great news! I'm from Facebook OpenBMC team, and I'm working on enabling your Linux tree in Facebook OpenBMC and later contributing fixes back to the community.

Thank you for the feedback.

> I found a lot of good documents about how to contribute code, but I cannot find information regarding branching strategy and release timeline. For example,
>
> 1) what are the major reasons/factors to trigger the version upgrade (4.10 to 4.13 and then 4.17)?
>
> 2) Are we planning to keep OpenBMC linux kernel in-sync with Torvalds's tree or linux stable tree?
>
> 3) Since we are discussing OpenBMC release schedule in another thread, I'm curious how to align linux tree with OpenBMC release schedule? For example, creating tags for OpenBMC releases?

Last year I came up with a development process that aimed for very
regular rebasing on upstream:

 https://github.com/openbmc/linux/wiki/DevelopmentProcess#openbmc-kernel-maintainer

This was optimistic. In practice, I've not had the time to do this as
often as I would like. We have spent a lot of effort in the past year
on is getting code upstream, so that moving to a new base is as easy
as possible.

I would like to propose we try to move to the new kernel base as
mainline makes a new release. This would mean a three monthly cadence,
with the trigger being the tagging of the final release.

By keeping in sync with upstream, we will have community support from
the stable tree. I will merge these point releases (the z in x.y.z, eg
4.17.z) in as they are released.

My goal is to have OpenBMC products shipping mainline kernels with no
further patches. We are very close to this goal for OpenPower Power9
machines, and I look forward to supporting other platforms achieve
this too.

A non-goal is to maintain a long-lived stable tree, as this takes time
away from the first goal.

Cheers,

Joel