public inbox for kdevops@lists.linux.dev
 help / color / mirror / Atom feed
From: Chuck Lever <chuck.lever@oracle.com>
To: Luis Chamberlain <mcgrof@kernel.org>
Cc: Daniel Gomez <da.gomez@samsung.com>, Chuck Lever <cel@kernel.org>,
	Amir Goldstein <amir73il@gmail.com>,
	"kdevops@lists.linux.dev" <kdevops@lists.linux.dev>
Subject: Re: [PATCH 0/4] Drips and drabs
Date: Thu, 22 Feb 2024 13:28:08 -0500	[thread overview]
Message-ID: <ZdeSOCjvVrlLpDIw@manet.1015granger.net> (raw)
In-Reply-To: <Zdd1a4puR-Lxg7Pa@bombadil.infradead.org>

On Thu, Feb 22, 2024 at 08:25:15AM -0800, Luis Chamberlain wrote:
> On Thu, Feb 22, 2024 at 04:11:53PM +0000, Daniel Gomez wrote:
> > On Thu, Feb 22, 2024 at 07:35:40AM -0800, Luis Chamberlain wrote:
> > > On Thu, Feb 22, 2024 at 10:25:59AM -0500, Chuck Lever wrote:
> > > > Here are some patches that begin adding support for aarch64 with
> > > > libguestfs. It's not fully working yet, but these seem sensible
> > > > enough to start with.
> > > > 
> > > > ---
> > > > 
> > > > Chuck Lever (4):
> > > >       linux: Add the 5.15.y stable branch
> > > >       Kconfig: Remove unused Kconfig option
> > > >       Kconfig: Default value of TARGET_ARCHITECTURE
> > > >       libvirt: Select qemu executable based on host architecture
> > > > 
> > > 
> > > All look good to me, however Daniel Gomez's new ref tag stuff may
> > > conflict with patch #1, so its unclear if this should go in as is
> > > or we shoud wait for Daniel's changes as it woud allow you later to
> > > easily bump the extra version for a stable kernel. That's a feature
> > > which I think Amir has also been yearning for.
> > 
> > I think we can drop that patch Chuck. I would only have to increase the number
> > of refs to 16 for stable, so the 5.15.y branch is included.
> > 
> > Here the snippet with 16 refs:
> > 
> > config BOOTLINUX_TREE_STABLE_REF
> >         string
> >         default "master" if BOOTLINUX_TREE_STABLE_REF_0
> >         default "linux-rolling-stable" if BOOTLINUX_TREE_STABLE_REF_1
> >         default "linux-rolling-lts" if BOOTLINUX_TREE_STABLE_REF_2
> >         default "linux-6.7.y" if BOOTLINUX_TREE_STABLE_REF_3
> >         default "linux-6.6.y" if BOOTLINUX_TREE_STABLE_REF_4
> >         default "linux-6.5.y" if BOOTLINUX_TREE_STABLE_REF_5
> >         default "linux-6.4.y" if BOOTLINUX_TREE_STABLE_REF_6
> >         default "linux-6.3.y" if BOOTLINUX_TREE_STABLE_REF_7
> >         default "linux-6.2.y" if BOOTLINUX_TREE_STABLE_REF_8
> >         default "linux-6.1.y" if BOOTLINUX_TREE_STABLE_REF_9
> >         default "linux-6.0.y" if BOOTLINUX_TREE_STABLE_REF_10
> >         default "linux-5.19.y" if BOOTLINUX_TREE_STABLE_REF_11
> >         default "linux-5.18.y" if BOOTLINUX_TREE_STABLE_REF_12
> >         default "linux-5.17.y" if BOOTLINUX_TREE_STABLE_REF_13
> >         default "linux-5.16.y" if BOOTLINUX_TREE_STABLE_REF_14
> >         default "linux-5.15.y" if BOOTLINUX_TREE_STABLE_REF_15
> >         default "v6.8-rc5" if BOOTLINUX_TREE_STABLE_REF_16
> >         default "v6.8-rc4" if BOOTLINUX_TREE_STABLE_REF_17
> >         default "v6.8-rc3" if BOOTLINUX_TREE_STABLE_REF_18
> >         default "v6.8-rc2" if BOOTLINUX_TREE_STABLE_REF_19
> >         default "v6.8-rc1" if BOOTLINUX_TREE_STABLE_REF_20
> >         default "v6.7.5" if BOOTLINUX_TREE_STABLE_REF_21
> >         default "v6.7.4" if BOOTLINUX_TREE_STABLE_REF_22
> >         default "v6.7.3" if BOOTLINUX_TREE_STABLE_REF_23
> >         default "v6.7.2" if BOOTLINUX_TREE_STABLE_REF_24
> >         default "v6.7.1" if BOOTLINUX_TREE_STABLE_REF_25
> >         default "v6.7" if BOOTLINUX_TREE_STABLE_REF_26
> >         default "v6.7-rc8" if BOOTLINUX_TREE_STABLE_REF_27
> >         default "v6.7-rc7" if BOOTLINUX_TREE_STABLE_REF_28
> >         default "v6.7-rc6" if BOOTLINUX_TREE_STABLE_REF_29
> >         default "v6.7-rc5" if BOOTLINUX_TREE_STABLE_REF_30
> >         default "v6.7-rc4" if BOOTLINUX_TREE_STABLE_REF_31
> 
> Perhaps we should not include rc candidates for stabe branches. That
> should limit the number of refs needed. Is that easy to do?
> 
>   Luis

Agreed, I prefer pulling the stable branches rather than a tag,
so this is nicer than my patch, which I will drop. I agree the
-rc tags don't add much value over linux-next, and will have to
be actively maintained.

-- 
Chuck Lever

      reply	other threads:[~2024-02-22 18:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-22 15:25 [PATCH 0/4] Drips and drabs Chuck Lever
2024-02-22 15:26 ` [PATCH 1/4] linux: Add the 5.15.y stable branch Chuck Lever
2024-02-22 15:26 ` [PATCH 2/4] Kconfig: Remove unused Kconfig option Chuck Lever
2024-02-22 15:26 ` [PATCH 3/4] Kconfig: Default value of TARGET_ARCHITECTURE Chuck Lever
2024-02-22 15:26 ` [PATCH 4/4] libvirt: Select qemu executable based on host architecture Chuck Lever
2024-02-22 15:35 ` [PATCH 0/4] Drips and drabs Luis Chamberlain
2024-02-22 16:11   ` Daniel Gomez
2024-02-22 16:25     ` Luis Chamberlain
2024-02-22 18:28       ` Chuck Lever [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=ZdeSOCjvVrlLpDIw@manet.1015granger.net \
    --to=chuck.lever@oracle.com \
    --cc=amir73il@gmail.com \
    --cc=cel@kernel.org \
    --cc=da.gomez@samsung.com \
    --cc=kdevops@lists.linux.dev \
    --cc=mcgrof@kernel.org \
    /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