Re: [PATCH v3] releases: use newer compression methods for tarballs

[Jan Beulich <jbeulich@xxxxxxxx>]

On 14.09.2025 18:59, Oleksii Kurochko wrote:
> 
> On 9/14/25 3:43 PM, Jan Beulich wrote:
>> On 12.09.2025 23:23, Julien Grall wrote:
>>> On 11/09/2025 09:14, Jan Beulich wrote:
>>>> Other projects have long switched to xz and/or lzip.
>>>>
>>>> Tidy things some as well: With the removal of qemu from the tarball,
>>>> intermediately extracting the tarball again has become wasteful. Drop
>>>> that. Invoke compressors using asynchronous lists, to reduce overall
>>>> latency. Drop the -v option from the (previously implicit) gzip
>>>> invocation.
>>>>
>>>> Signed-off-by: Jan Beulich<jbeulich@xxxxxxxx>
>>> I have tested manually the steps and the correct tarballs have been
>>> produced. I will update my scripts to copy & sign all the tarballs once
>>> this is merged.
>>>
>>> Acked-by: Julien Grall<jgrall@xxxxxxxxxx>
>>> Tested-by: Julien Grall<jgrall@xxxxxxxxxx>
>> Thanks.
>>
>>> Is this intended for Xen 4.21?
> 
> IMO, it would be nice to have that in Xen 4.21.

May I translate this to a release-ack then?

>> So far it was, but I'm increasingly unsure, seeing that it still hasn't
>> gone in. Cc-ing Oleksii too now. Andrew had voiced concern towards the
>> rm use, but hasn't come back as to his argument towards the uncompressed
>> tarball previously not having been removed (when I can't see that one
>> would have been created in the first place), hence why I couldn't make
>> use of his (conditional) R-b.
> 
> There is not too much sense in the uncompressed tarball. I prefer to not
> generate it at all.

Generating is helpful, to do it only once (instead of once per compressed
tarball).

> Also I have regarding .gz. If other projects switched to xz and/or
> lzip (as it is mentioned in the commit message) what is the purpose of
> having .gz tarball then?

At the very least to help people presently assuming they'll find a .gz.

Jan