linux-rt-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florian Bezdeka <florian.bezdeka@siemens.com>
To: Daniel Wagner <wagi@monom.org>
Cc: "Luis Claudio R. Goncalves" <lgoncalv@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-rt-users <linux-rt-users@vger.kernel.org>,
	stable-rt <stable-rt@vger.kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Carsten Emde <C.Emde@osadl.org>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Daniel Wagner <daniel.wagner@suse.com>,
	Tom Zanussi <tom.zanussi@linux.intel.com>,
	Clark Williams <williams@redhat.com>,
	Mark Gross <markgross@kernel.org>, Pavel Machek <pavel@denx.de>,
	Jeff Brady <jeffreyjbrady@gmail.com>,
	Salvatore Bonaccorso <carnil@debian.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Jan Kiszka <jan.kiszka@siemens.com>
Subject: Re: [ANNOUNCE] 5.10.162-rt79
Date: Fri, 03 Mar 2023 09:29:28 +0100	[thread overview]
Message-ID: <21e61d098cd78476770b8a0e782689c76ff30d80.camel@siemens.com> (raw)
In-Reply-To: <20230223143356.fa6tqrflmhrcqx33@carbon.lan>

On Thu, 2023-02-23 at 15:33 +0100, Daniel Wagner wrote:
> Hi Florian,
> 
> On Thu, Jan 26, 2023 at 06:41:27PM +0100, Florian Bezdeka wrote:
> > From the CIP projects perspective we would like to improve the
> > situation.
> > 
> > From my perspective the following could be done:
> > 
> >   - Instead of (or in addition to) building and testing released -rt
> >     branches enable testing of -rt release candidates
> >   - Make sure the build results get back to the maintainers
> > 
> > I'm not sure if every -rt branch has a -rc branch. I'm not familiar
> > with the -rt release process yet.
> 
> The process so far is, that every stable maintainer updates his tree (merges the
> stable tree) and does a local build and local tests. Usually when merging latest
> upstream stable release there are no or little fallouts. When the maintainer is
> happy he does the release by pushing the changes to the usptream branch. The
> release candiates come only into play when there is something the maintainer is
> not sure how to handle or -rt patches are backported which need some more eyes
> to look on. That means Sebastian's approval :)

Ok, so there are no automated test for each release.

> 
> IIRC, I did give a presentation on the workflow some time ago...
> 
> https://lpc.events/event/4/contributions/293/attachments/237/416/maintaining-out-of-tree-patches-over-the-long-term.pdf
> https://www.youtube.com/watch?v=2ab4Knwlmo4

Thanks for the hint!

> 
> When we started with this process kernelci didn't build these branches but that
> is long time ago.

At least (some) stable release branches are being build now but it
seems that nobody is caring about the result. That's one of the things
I would like to address.

> 
> Personally, I don't mind doing an official -rc for every release and getting
> some additional builds and tests run by kernelci.

Ok, but that would be something that "all" -rt-stable maintainers
should agree on, no? At least to some degree to make the testing part
consistent.

> 
> Though just piping the results back is the easy thing, the time consuming task
> is to fix those problems. Do you plan to help out here?

Well, having the pipelines might be easy, but we don't have them yet, 
right? Reacting on the pipeline results would be the next step that
possibly could happen in cooperation with the CIP project.

But yes, generally speaking we want to help. But we don't have infinite
resources (as usual), so we'd like to know where most impact could be
achieved.

Are there any plans to build and test the stable -rt branches with the
help of automation, for example by using the kernelci infrastructure?
If no: Would that be something that the RT project is interested in?

I'm asking for kernelci because the CIP project is already using that.
They defined a clear set of supported architectures, kernel configs,
test suites and concrete hardware (to some degree). This allows them to
make sure each release candidate of each branch is in good shape before
doing the actual release.

Regards,
Florian

> 
> Thanks,
> Daniel


      reply	other threads:[~2023-03-03  8:29 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-26 14:31 [ANNOUNCE] 5.10.162-rt79 Luis Claudio R. Goncalves
2023-01-26 17:41 ` Florian Bezdeka
2023-02-23 14:33   ` Daniel Wagner
2023-03-03  8:29     ` Florian Bezdeka [this message]

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=21e61d098cd78476770b8a0e782689c76ff30d80.camel@siemens.com \
    --to=florian.bezdeka@siemens.com \
    --cc=C.Emde@osadl.org \
    --cc=bigeasy@linutronix.de \
    --cc=carnil@debian.org \
    --cc=daniel.wagner@suse.com \
    --cc=jan.kiszka@siemens.com \
    --cc=jeffreyjbrady@gmail.com \
    --cc=lgoncalv@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=markgross@kernel.org \
    --cc=pavel@denx.de \
    --cc=rostedt@goodmis.org \
    --cc=stable-rt@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tom.zanussi@linux.intel.com \
    --cc=wagi@monom.org \
    --cc=williams@redhat.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;
as well as URLs for NNTP newsgroup(s).