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

[George Dunlap <George.Dunlap@xxxxxxxxxx>]

> On Sep 30, 2020, at 9:23 PM, Stefano Stabellini <sstabellini@xxxxxxxxxx> 
> wrote:
> 
> On Wed, 30 Sep 2020, George Dunlap 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_.
> 
> Alpine Linux should be in the list (consider its usage in container
> environment.)

Sure, we can add that one in.  Although, we might consider requiring that 
distros on this list be first be added to the Gitlab CI loop if possible.

> I am still on Alpine Linux 3.7, so I am sure that one works. Probably
> other versions work too.

Right, but the question is, if someone posts a patch which causes it to no 
longer build on 3.7, would we reject it or accept it?

According to https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases, only 3.12 
is currently receiving bug fixes; so by the criteria above, we would only 
reject a changeset if it caused a build regression for 3.12.

I would argue that this is the right approach: It doesn’t make sense for us to 
spend more effort keeping an old distro working than that community it self 
spends keeping it working.  The Ubuntu community spends effort keeping Ubuntu 
16.04 in working shape, so it makes sense for us to spend effort making sure 
Xen 4.15 builds and runs on it.  The Alpine Linux community doesn’t promise to 
spend any effort to fix any more bugs in Alpine Linux 3.11, so it doesn’t make 
any sense for us to spend effort making sure Xen 4.15 runs on it.

Obviously if it builds on Ubuntu 16.04 there’s a pretty high probability that 
it will also build on Alpine Linux 3.4+ (released around the same time); we 
just don’t want to promise that.

 -George