On 31/10/2024 10:02 am, Jan Beulich wrote:
> On 31.10.2024 10:46, Andrew Cooper wrote:
>> On 31/10/2024 9:25 am, Jan Beulich wrote:
>>> On 30.10.2024 19:03, Andrew Cooper wrote:
>>>> A new branch from xen-RELEASE-4.19.0, for now containing commit
>>>> a400dd517068 ("Add missing symbol exports for grub-pv").
>>>>
>>>> Signed-off-by: Andrew Cooper <[email protected]>
>>>> ---
>>>> CC: Juergen Gross <[email protected]>
>>>> CC: Jan Beulich <[email protected]>
>>>> CC: Stefano Stabellini <[email protected]>
>>>> CC: Julien Grall <[email protected]>
>>>> ---
>>>> Config.mk | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/Config.mk b/Config.mk
>>>> index 03a89624c77f..aa3d5843f1ed 100644
>>>> --- a/Config.mk
>>>> +++ b/Config.mk
>>>> @@ -224,7 +224,7 @@ QEMU_UPSTREAM_URL ?=
>>>> https://xenbits.xen.org/git-http/qemu-xen.git
>>>> QEMU_UPSTREAM_REVISION ?= qemu-xen-4.19.0
>>>>
>>>> MINIOS_UPSTREAM_URL ?= https://xenbits.xen.org/git-http/mini-os.git
>>>> -MINIOS_UPSTREAM_REVISION ?= xen-RELEASE-4.19.0
>>>> +MINIOS_UPSTREAM_REVISION ?= xen-stable-4.19
>>> Wouldn't we better use a hash here, like we do on staging? There had been
>>> cases where it wasn't safe for the used commit to move "automatically", and
>>> the same could occur on a stable branch. The hash would then be replaced by
>>> a release tag when a release is being prepared (again like on staging).
>> It will only be getting build fixes, not new content. So it will be
>> stable-enough in that regard.
> Hmm, can we really expect it to only ever be build fixes, not fixes of any
> other kind (which then may have dependencies)? Jürgen, Samuel, what's your
> take?
The reason I needed to make a branch (and I've got 4.18 (shared with
4.17) and 4.16 also queued up) is to avoid taking intermediate changes
while backporting a build fix.
The last time this happened was Xen 4.6.
The reasoning would be different if we backported new features, but we
don't as a matter of course.
~Andrew
