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 at gmail.com on behalf of Joel Stanley" <joel.stan at gmail.com on behalf of joel at jms.id.au> wrote:

    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