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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Thu, 1 Oct 2020, George Dunlap wrote:
> > 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.

OK