Re: [PATCH RFC] docs: Add minimum version depencency policy document

[Bertrand Marquis <Bertrand.Marquis@xxxxxxx>]

Hi Christopher,

> On 2 Oct 2020, at 07:25, Christopher Clark <christopher.w.clark@xxxxxxxxx> 
> wrote:
> 
> On Thu, Oct 1, 2020 at 7:38 AM Bertrand Marquis
> <Bertrand.Marquis@xxxxxxx> wrote:
>> 
>> Hi George,
>> 
>> + Christopher Clark to have his view on what to put for Yocto.
>> 
>>> On 30 Sep 2020, at 13:57, George Dunlap <george.dunlap@xxxxxxxxxx> wrote:
>>> 
>>> Define a specific criteria for how we determine what tools and
>>> libraries to be compatible with.  This will clarify issues such as,
>>> "Should we continue to support Python 2.4" moving forward.
>>> 
>>> Note that CentOS 7 is set to stop receiving "normal" maintenance
>>> updates in "Q4 2020"; assuming that 4.15 is released after that, we
>>> only need to support CentOS / RHEL 8.
>>> 
>>> Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxx>
>>> ---
>>> 
>>> CC: Ian Jackson <ian.jackson@xxxxxxxxxx>
>>> CC: Wei Liu <wl@xxxxxxx>
>>> CC: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>>> CC: Jan Beulich <jbeulich@xxxxxxxx>
>>> CC: Stefano Stabellini <sstabellini@xxxxxxxxxx>
>>> CC: Julien Grall <julien@xxxxxxx>
>>> CC: Rich Persaud <persaur@xxxxxxxxx>
>>> CC: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
>>> ---
>>> docs/index.rst                        |  2 +
>>> docs/policies/dependency-versions.rst | 76 +++++++++++++++++++++++++++
>>> 2 files changed, 78 insertions(+)
>>> create mode 100644 docs/policies/dependency-versions.rst
>>> 
>>> diff --git a/docs/index.rst b/docs/index.rst
>>> index b75487a05d..ac175eacc8 100644
>>> --- a/docs/index.rst
>>> +++ b/docs/index.rst
>>> @@ -57,5 +57,7 @@ Miscellanea
>>> -----------
>>> 
>>> .. toctree::
>>> +   :maxdepth: 1
>>> 
>>> +   policies/dependency-versions
>>>   glossary
>>> diff --git a/docs/policies/dependency-versions.rst 
>>> b/docs/policies/dependency-versions.rst
>>> new file mode 100644
>>> index 0000000000..d5eeb848d8
>>> --- /dev/null
>>> +++ b/docs/policies/dependency-versions.rst
>>> @@ -0,0 +1,76 @@
>>> +.. SPDX-License-Identifier: CC-BY-4.0
>>> +
>>> +Build and runtime dependencies
>>> +==============================
>>> +
>>> +Xen depends on other programs and libraries to build and to run.
>>> +Chosing a minimum version of these tools to support requires a careful
>>> +balance: Supporting older versions of these tools or libraries means
>>> +that Xen can compile on a wider variety of systems; but means that Xen
>>> +cannot take advantage of features available in newer versions.
>>> +Conversely, requiring newer versions means that Xen can take advantage
>>> +of newer features, but cannot work on as wide a variety of systems.
>>> +
>>> +Specific dependencies and versions for a given Xen release will be
>>> +listed in the toplevel README, and/or specified by the ``configure``
>>> +system.  This document lays out the principles by which those versions
>>> +should be chosen.
>>> +
>>> +The general principle is this:
>>> +
>>> +    Xen should build on currently-supported versions of major distros
>>> +    when released.
>>> +
>>> +"Currently-supported" means whatever that distro's version of "full
>>> +support".  For instance, at the time of writing, CentOS 7 and 8 are
>>> +listed as being given "Full Updates", but CentOS 6 is listed as
>>> +"Maintenance updates"; under this criterium, we would try to ensure
>>> +that Xen could build on CentOS 7 and 8, but not on CentOS 6.
>>> +
>>> +Exceptions for specific distros or tools may be made when appropriate.
>>> +
>>> +One exception to this is compiler versions for the hypervisor.
>>> +Support for new instructions, and in particular support for new safety
>>> +features, may require a newer compiler than many distros support.
>>> +These will be specified in the README.
>>> +
>>> +Distros we consider when deciding minimum versions
>>> +--------------------------------------------------
>>> +
>>> +We currently aim to support Xen building and running on the following 
>>> distributions:
>>> +Debian_,
>>> +Ubuntu_,
>>> +OpenSUSE_,
>>> +Arch Linux,
>>> +SLES_,
>>> +Yocto_,
>>> +CentOS_,
>>> +and RHEL_.
>>> +
>>> +.. _Debian: https://www.debian.org/releases/
>>> +.. _Ubuntu: https://wiki.ubuntu.com/Releases
>>> +.. _OpenSUSE: https://en.opensuse.org/Lifetime
>>> +.. _SLES: https://www.suse.com/lifecycle/
>>> +.. _Yocto: https://wiki.yoctoproject.org/wiki/Releases
>>> +.. _CentOS: https://wiki.centos.org/About/Product
>>> +.. _RHEL: https://access.redhat.com/support/policy/updates/errata
>>> +
>>> +Specific distro versions supported in this release
>>> +--------------------------------------------------
>>> +
>>> +======== ==================
>>> +Distro   Supported releases
>>> +======== ==================
>>> +Debian   10 (Buster)
>>> +Ubuntu   20.10 (Groovy Gorilla), 20.04 (Focal Fossa), 18.04 (Bionic 
>>> Beaver), 16.04 (Xenial Xerus)
>>> +OpenSUSE Leap 15.2
>>> +SLES     SLES 11, 12, 15
>>> +Yocto    3.1 (Dunfell)
>> 
>> Yocto only supports one version of Xen (as there is usually only one xen 
>> recipe per yocto version)
> 
> I'm not sure that's totally accurate: the Yocto Xen recipes are
> written to support backwards compatibility with older versions of Xen.
> In general, care and effort has been expended to support building with
> multiple versions of Xen with the same recipes, via variable override
> or bbappend, and it is expected to work.

I agree when the latest version of meta-virtualization is used (at least
for now).

> 
>> which can make the version here a bit tricky:
>> Yocto 3.1 (Dunfell) supports only Xen 4.12
>> Yocto 3.2 (Gategarth) support only Xen 4.14 but has a Yocto master recipe 
>> which should actually be used
>> by someone who would want to try Xen master.
>> 
>> So I would suggest to put Yocto 3.2 here only.
>> 
>> @Christopher: what is your view here ?
> 
> Thanks for asking. I don't quite agree with that recommendation: I
> think Dunfell does belong, with an indication that it requires
> Gatesgarth meta-virtualization. Dunfell is the LTS release, so a
> compatibility statement about it is important. ie:
> 
> Yocto 3.1 (Dunfell + Gatesgarth meta-virtualization)

Agree this is what we should say and add:

Yocto 3.2 (Gatesgarth)

> 
> Effort has already been made within Yocto to make the Gatesgarth
> meta-virtualization layer compatible with Dunfell open-embedded core,
> specifically to allow newer Xen to be used with the LTS Dunfell
> software from the core layers. I would hope that any issues that are
> found with that configuration will be posted so they can be fixed.
> 

I must admit i never tested the combination that way but I will check
if such a scenario could be added to the tests we define internally at arm.

Thanks for the answers

Cheers
Bertrand

> thanks,
> 
> Christopher
> 
>> 
>> Cheers
>> Bertrand
>> 
>>> +CentOS   8
>>> +RHEL     8
>>> +======== ==================
>>> +
>>> +.. note::
>>> +
>>> +   We also support Arch Linux, but as it's a rolling distribution, the
>>> +   concept of "security supported releases" doesn't really apply.
>>> --
>>> 2.25.1