From: Bruce Ashfield <bruce.ashfield@gmail.com>
To: Christopher Clark <christopher.w.clark@gmail.com>
Cc: Michal.Orzel@amd.com, meta-virtualization@lists.yoctoproject.org
Subject: Re: [meta-virtualization][PATCH 0/2] xen: follow-up to recent recipes update
Date: Mon, 4 Dec 2023 15:36:08 -0500 [thread overview]
Message-ID: <CADkTA4PniZvWt_ZFZeDrs1ED+TdHu2DYypgoUVMEJWSJSui1UQ@mail.gmail.com> (raw)
In-Reply-To: <CACMJ4GZAXXVpiaAXJZt_z6Ev1bw1AieG2_Qotgtx3RUpVm83Sw@mail.gmail.com>
On Tue, Nov 28, 2023 at 12:45 PM Christopher Clark
<christopher.w.clark@gmail.com> wrote:
>
> On Tue, Nov 28, 2023 at 5:49 AM Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
>>
>> On Tue, Nov 28, 2023 at 7:56 AM Bruce Ashfield via
>> lists.yoctoproject.org
>> <bruce.ashfield=gmail.com@lists.yoctoproject.org> wrote:
>> >
>> > On Tue, Nov 28, 2023 at 3:42 AM Orzel, Michal via
>> > lists.yoctoproject.org <Michal.Orzel=amd.com@lists.yoctoproject.org>
>> > wrote:
>> > >
>> > > On 28/11/2023 04:11, Christopher Clark wrote:
>> > > >
>> > > > On Mon, Nov 27, 2023 at 6:08 AM Michal Orzel <michal.orzel@amd.com <mailto:michal.orzel@amd.com>> wrote:
>> > > >
>> > > > On 27/11/2023 14:55, Bruce Ashfield wrote:
>> > > > >
>> > > > > On Mon, Nov 27, 2023 at 5:38 AM Michal Orzel <michal.orzel@amd.com <mailto:michal.orzel@amd.com>> wrote:
>> > > > >>
>> > > > >> Some follow-up patches after a recent Xen recipes update.
>> > > > >>
>> > > > >> Open question:
>> > > > >> Shouldn't we set 4.18 as a default version?
>> > > > >
>> > > > > Not yet (and definitely not for nanbield). Perhaps once it has been under
>> > > > > test for a few weeks. I did the updates to get them some extra soak time
>> > > > > and make them available in both the upcoming release (nanbield) and
>> > > > > master for those that want to use the latest, without making it a default
>> > > > > version jump so late in the cycle.
>> > > > Ok.
>> > > >
>> > > > Thanks, Bruce.
>> > > >
>> > > > > As for the changes in master, the 4.18 version on the _git recipes is
>> > > > > intentional, as there's been no 4.19 tag that I can find and I don't bump
>> > > > > versions until I see that in the repo .. so for now, it is just the +git
>> > > > > and +stable that is the difference between the 4.18 and _git versions.
>> > > > You won't see any 4.19 tag until the next release. The version is advertised in
>> > > > the main Makefile [1] and this is what user can see in the system
>> > > > (e.g. in the boot log, xl info, xen_version hypercall).
>> > > > Bumping the XEN_REL of master recipes
>> > > >
>> > > > I think it could be helpful for the context of this thread to describe them as the "git recipes" rather than using the term "master recipe", because the latter unfortunately seems to convey that they are somehow superior to the other, versioned, Xen recipes, when in practice they are not -- they are deliberately not the default version of Xen that is built since, as you note, they are defined:
>> > > >
>> > > > to reflect the current development version
>> > > >
>> > > > of Xen. ie. The git recipes are present alongside the other recipes that provide the stable release version(s) of Xen.
>> > > >
>> > > > As Michal has noted above, putting 4.19 for XEN_REL into the git recipe does look right from a Xen source tree perspective for that SRCREV, even though there is not a 4.19 Xen release, but the proposed commit message should be updated to avoid the term "master recipe".
>> > > Sounds good to me.
>> > >
>> > > @Bruce, may I please ask you to take my patch modifying XEN_REL and do s/master/git in title on commit?
>> > > If not, I will push a v2 of this patch.
>> >
>> > Regardless of what I've done in the past, I'm still inclined to hold
>> > the line on the versioning until at least the first -rc is released.
>> >
>>
>> FWIW, I also don't change the version of the linux-yocto-dev kernels
>> until a valid
>> -rc1 is released, even though the "version' has moved on from the previous
>> release.
>>
>> That being said, until I find a better option to keep the versions reported via
>> the runtime to match the package version, I can either bump the version or
>> hold / revert the _git recipe until the first release candidates are out.
>>
>> I'll go ahead and stage the change with the fixup, even if I don't like the
>> version management scheme :)
>
>
> Thanks for the extra info, Bruce. So there is still a way to meet your versioning scheme and have the runtime version match the package version by changing the default Xen branch selector in the git recipe via the XEN_BRANCH variable to the latest stable branch, thus:
>
After some additional poking around, I do want the recipe to follow master,
since I should be keeping the 4.18 recipes up with the latest tip (I don't
typically wait for releases to bump SRCREVs) of the same branch.
Even though I don't like not having a -rc tag before bumping the version,
there's no way around it in this case.
I've tweaked the message and pushed this to master and nanbield.
Bruce
> diff --git a/recipes-extended/xen/xen_git.bb b/recipes-extended/xen/xen_git.bb
> index 784e71ce..547a7943 100644
> --- a/recipes-extended/xen/xen_git.bb
> +++ b/recipes-extended/xen/xen_git.bb
> @@ -2,7 +2,7 @@
> SRCREV ?= "f96e2f64576cdbb147391c7cb399d393385719a9"
>
> XEN_REL ?= "4.18"
> -XEN_BRANCH ?= "master"
> +XEN_BRANCH ?= "stable-4.18"
>
> SRC_URI = " \
> git://xenbits.xen.org/xen.git;branch=${XEN_BRANCH} \
>
> and then anyone building a development version of Xen can update both the XEN_BRANCH and XEN_REL variables to match the revision that they are choosing to build.
> Does that look OK?
>
> Or another option is to use the XEN_REL value to select the default stable branch to use:
>
> diff --git a/recipes-extended/xen/xen_git.bb b/recipes-extended/xen/xen_git.bb
> index 784e71ce..35e6b859 100644
> --- a/recipes-extended/xen/xen_git.bb
> +++ b/recipes-extended/xen/xen_git.bb
> @@ -2,7 +2,7 @@
> SRCREV ?= "f96e2f64576cdbb147391c7cb399d393385719a9"
>
> XEN_REL ?= "4.18"
> -XEN_BRANCH ?= "master"
> +XEN_BRANCH ?= "stable-${XEN_REL}"
>
> SRC_URI = " \
> git://xenbits.xen.org/xen.git;branch=${XEN_BRAN
>
> Christopher
>
>
>>
>>
>> Bruce
>>
>> > Bruce
>> >
>> > >
>> > > ~Michal
>> > >
>> > >
>> > >
>> >
>> >
>> > --
>> > - Thou shalt not follow the NULL pointer, for chaos and madness await
>> > thee at its end
>> > - "Use the force Harry" - Gandalf, Star Trek II
>> >
>> > -=-=-=-=-=-=-=-=-=-=-=-
>> > Links: You receive all messages sent to this group.
>> > View/Reply Online (#8479): https://lists.yoctoproject.org/g/meta-virtualization/message/8479
>> > Mute This Topic: https://lists.yoctoproject.org/mt/102826507/1050810
>> > Group Owner: meta-virtualization+owner@lists.yoctoproject.org
>> > Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/leave/6693017/1050810/978058475/xyzzy [bruce.ashfield@gmail.com]
>> > -=-=-=-=-=-=-=-=-=-=-=-
>> >
>>
>>
>> --
>> - Thou shalt not follow the NULL pointer, for chaos and madness await
>> thee at its end
>> - "Use the force Harry" - Gandalf, Star Trek II
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
prev parent reply other threads:[~2023-12-04 20:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-27 10:38 [meta-virtualization][PATCH 0/2] xen: follow-up to recent recipes update Michal Orzel
2023-11-27 10:38 ` [meta-virtualization][PATCH 1/2] xen: Bump SRCREV of 4.17 recipes to 4.17.2 Michal Orzel
2023-11-27 10:38 ` [meta-virtualization][PATCH 2/2] xen: Set XEN_REL to 4.19 for master recipes Michal Orzel
2023-11-27 13:55 ` [meta-virtualization][PATCH 0/2] xen: follow-up to recent recipes update Bruce Ashfield
2023-11-27 14:08 ` Michal Orzel
2023-11-28 3:11 ` Christopher Clark
2023-11-28 8:41 ` Michal Orzel
2023-11-28 12:55 ` Bruce Ashfield
[not found] ` <179BCAB522548B7D.22216@lists.yoctoproject.org>
2023-11-28 13:49 ` Bruce Ashfield
2023-11-28 17:45 ` Christopher Clark
2023-12-04 20:36 ` Bruce Ashfield [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=CADkTA4PniZvWt_ZFZeDrs1ED+TdHu2DYypgoUVMEJWSJSui1UQ@mail.gmail.com \
--to=bruce.ashfield@gmail.com \
--cc=Michal.Orzel@amd.com \
--cc=christopher.w.clark@gmail.com \
--cc=meta-virtualization@lists.yoctoproject.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).