On 31/10/2024 10:24 am, Andrew Cooper wrote:
> 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.
The failure to make git-checkout.sh work with branches forces an answer
here. I'm going to need to use full SHA.
~Andrew
