From: "Mills, William" <wmills@ti.com>
To: "linux-rt-users@vger.kernel.org" <linux-rt-users@vger.kernel.org>
Cc: "Murphy, Dan" <dmurphy@ti.com>, "Nori, Sekhar" <nsekhar@ti.com>
Subject: Linux stable vs RT stable and RT dev
Date: Fri, 2 Feb 2018 19:00:12 +0000 [thread overview]
Message-ID: <8155aea247374c058bd7c797124c3d28@ti.com> (raw)
Hello,
I am trying to understand the policy WRT the RT stable branches and the Linux stable releases.
It appears not every Linux stable gets its own RT stable. [1]
What is the goal?
Not getting behind by more than X weeks?
Only change when RT series needs to be updated?
What is the expected consumer model?:
Use only the version published by the maintainer
Merge in upstream point release themselves between rt-stable releases
How is the policy different for rt-dev vs rt-stable?
I know Steven wrote up a stable RT maintainer's howto but I did not find it. Can I get a pointer?
I did find Steven's slides from 2106[2] and skimmed them.
[1] https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.4/older/
[2] https://wiki.linuxfoundation.org/_media/realtime/events/rt-summit2016/how-much-stable-do-we-need_steven-rostedt.pdf
Long version / background
-----------------------------------------------------------------------------------
TI publishes 3 variants of our kernel for customers:
Base + TI + [Linaro LSK]
Base + TI + RT
Base + TI + Android Common
All this is based on the latest GKH LTS and there is maintenance of last years LTS
(Yes we understand this is all very simple if the TI set is nil. We have never achieved that to date. In the very least it is backports from tip to latest LTS. In reality it is more.)
Right now Base above is always the very latest stable from GKH LTS. It is auto merged as soon as it is published and picked up by our nightly builds. Any merge conflict in any of the variants stops auto merge progress.
In this structure we tend to be the first to merge RT with a new stable. Most of the time this is OK but sometimes it is not.
Is it reasonable / expected for us to get ahead of you or should we arrange things to just wait?
I used 4.9 in this example but right now we are executing this on 4.14, 4.9, and (somewhat) 4.4.
Thanks,
Bill
---------------------------------------------------
William A. Mills
Chief Technologist, Open Source
Texas Instruments, Processors
20450 Century Blvd
Germantown MD, 20874
(work/mobile) +1-240-643-0836
next reply other threads:[~2018-02-02 19:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-02 19:00 Mills, William [this message]
2018-02-02 21:46 ` Linux stable vs RT stable and RT dev Julia Cartwright
2018-02-03 1:20 ` William Mills
2018-02-05 21:17 ` Dan Murphy
2018-02-06 14:34 ` Sebastian Andrzej Siewior
2018-02-06 15:47 ` Dan Murphy
2018-02-06 16:17 ` Steven Rostedt
2018-02-06 20:07 ` Dan Murphy
2018-02-09 17:39 ` Sebastian Andrzej Siewior
2018-02-09 18:59 ` Dan Murphy
2018-02-09 19:30 ` Sebastian Andrzej Siewior
2018-02-09 19:43 ` Dan Murphy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8155aea247374c058bd7c797124c3d28@ti.com \
--to=wmills@ti.com \
--cc=dmurphy@ti.com \
--cc=linux-rt-users@vger.kernel.org \
--cc=nsekhar@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox