On Fri, 2020-02-07 at 16:21 +0000, Daniel P. Berrangé wrote: > While we have CI testing coverage for many platforms, we don't test any > non-GLibC based Linux and there are other non-Linux platforms we don't It's "glibc", not "GLibC". > officially target, both of which might hit regressions. > > Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com&gt; > --- > docs/news.xml | 19 +++++++++++++++++++ > 1 file changed, 19 insertions(+) > > diff --git a/docs/news.xml b/docs/news.xml > index f567a1182e..54ccc31abe 100644 > --- a/docs/news.xml > +++ b/docs/news.xml > @@ -84,6 +84,25 @@ > </change> > </section> > <section title="Improvements"> This belongs quite squarely in the "Packaging changes" section IMHO. > + <change> > + <summary> > + use of GNULIB has been completely eliminated Looking at the website and the git repository, it's either "gnulib" or "Gnulib", never "GNULIB". > + </summary> > + <description> > + Historically libvirt has embedded GNULIB to provide fixes for > + various platform portability problems. This usage has now been > + eliminated and alternative approaches for platform portability > + problems adopted where required. This has been validated on the > + set of platforms covered by automated CI build testing: Fedora > + 30, 31 and rawhide; CentOS 7 and 8; Debian 9 and 10; Ubuntu 18.04; > + FreeBSD 11 and 12; Mingw-w64; macOS 10.14 with XCode 10.3 and 11.3. I think listing all targets is a bit excessive. Also note that we don't actually have CentOS 8 CI coverage yet. > + Other Linux distros of a similar vintage using GLibC are expected > + to work. Linux distros using non-GLibC packages, and other > + non-Linux platforms may encounter regressions when building this > + release. Please report any build problems encountered back to the > + project maintainers for resolution. Should we include the caveat that we're still following our platform compatibility guidelines?