Re: [PATCH] RFC: Version support policy

[George Dunlap <George.Dunlap@xxxxxxxxxx>]

> On Feb 15, 2022, at 8:20 AM, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> 
> On 14.02.2022 22:50, George Dunlap wrote:
>>> On Aug 19, 2021, at 10:18 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>> On 13.08.2021 13:37, Ian Jackson wrote:
>>>> The current policy for minimum supported versions of tools, compilers,
>>>> etc. is unsatisfactory: For many dependencies no minimum version is
>>>> specified.  For those where a version is stated, updating it is a
>>>> decision that has to be explicitly taken for that tool.
>>> 
>>> Considering your submission of this having been close to a glibc
>>> version issue you and I have been discussing, I wonder whether
>>> "etc" above includes library dependencies as well.
>>> 
>>> In any event the precise scope of what is meant to be covered is
>>> quite important to me: There are affected entities that I'm happy
>>> to replace on older distros (binutils, gcc). There are potentially
>>> affected entities that I'm less happy to replace, but at the time
>>> I did work my way through it for example for Python (to still be
>>> able to build qemu, the community of which doesn't appear to care
>>> at all to have their stuff buildable in older environments). The
>>> point where I'd be really in trouble would be when base platform
>>> libraries like glibc are required to be a certain minimum version:
>>> I'd then be (potentially severely) restricted in what systems I
>>> can actually test stuff on.
>> 
>> The question here is, why would someone running a 10-year-old distro that’s 
>> been out of support for 6 years want to run a bleeding edge version of Xen?  
>> I understand wanting to run Xen 4.16 on (say) Ubuntu 18.04, but who on earth 
>> would want to run Xen 4.16 on Ubuntu 14.04, and why?  If such people exist, 
>> is it really worth the effort to try to support them?
> 
> I do this, for the very simple reason of wanting (needing) to be able
> to test a large range of Xen versions all on the same small set of
> hardware. Internally we're still maintaining versions back to at least
> 4.4; upon customer request we (I) may end up needing to even play with
> 4.0.

You don’t mention what software you’re talking about for versions 4.4 and 4.0, 
so I assume you mean Xen.

What I’m hearing you say is:

1. You have a handful of test hardware upon which you do your own manual 
testing.

2. You need to test at least as far back as Xen 4.4, possibly as far back as 
Xen 4.0, since you have customers that are using those versions.

3. It’s not feasible to test Xen 4.4 on a modern version of SUSE.  Presumably 
this is some combination of 3a. The customers using those versions are in fact 
using versions of SUSE from that timeframe as well, so thats what needs testing 
and 3b. It’s impractical to get Xen 4.4 to build on a modern version of SUSE.

4. It’s not feasible to use different SUSE versions on this hardware, such that 
each version of Xen is being tested with a version of SUSE from the appropriate 
time frame. Presumably this is some combination of 4a. You don’t want the 
hassle of re-installing the machine every time you want to test it (and it’s 
not feasible / too much of a hassle to maintain multiple parallel installations 
on the machine) 4b. Newer versions of SUSE wouldn’t run on this machine, since 
it’s so old.

Is that what I’m hearing?

So first of all, you are not an end-user, and running this sort of test is not 
“running Xen”.  I’m talking about end-users actually using Xen 4.16 “in anger” 
as they say in the UK, on Ubuntu 14.04; not for testing, but because they 
actually needed to use virtualization to solve a problem that they had.  Are 
there any people out there who need a hypervisor to solve a problem they have, 
and want to use Xen 4.16 with Ubuntu 14.04?

 -George

Attachment: signature.asc
Description: Message signed with OpenPGP