Re: Linux kenrel: Moving to a 4.17 base

Re: Linux kenrel: Moving to a 4.17 base

[Joel Stanley]

Hello Tao,

On 30 May 2018 at 17:57, Tao Ren <taoren@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

Re: Linux kenrel: Moving to a 4.17 base

[Tao Ren]

Got it. Thank you Joel for the detailed info.


Thanks,

Tao

On 5/30/18, 1:49 AM, "joel.stan@gmail.com on behalf of Joel Stanley" <joel.stan@gmail.com on behalf of joel@jms.id.au> wrote:

    Hello Tao,
    
    On 30 May 2018 at 17:57, Tao Ren <taoren@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
    

Re: Linux kenrel: Moving to a 4.17 base

[Stewart Smith]

Joel Stanley <joel@jms.id.au> writes:
> A non-goal is to maintain a long-lived stable tree, as this takes time
> away from the first goal.

Although syncing an openbmc release with an LTS kernel is probably a
good idea if someone wants a tree that's going to get some kind of
maintenance for a long time?

-- 
Stewart Smith
OPAL Architect, IBM.

Linux kenrel: Moving to a 4.17 base

[Joel Stanley]

Hello OpenBMCers,

On Monday I plan to push a 4.17 based tree to our Linux kernel
repository, and bump the in-tree machines to use this.

I've spent a bunch of time putting 4.17-rc7 through it's paces on a
Romulus machine, and it's looking good.

Cheers,

Joel