Re: [Qemu-devel] rawhide gcc failures [was: Proposal for deprecating unsupported host OSes & architecutures]

[Alex Bennée]

Peter Maydell <address@hidden> writes:

> On 22 March 2017 at 19:07, Eric Blake <address@hidden> wrote:
>> Tangentially-related: do we officially support bleeding-edge OS builds?
>> For example, current rawhide has a new-enough gcc that gives some
>> (possibly-useful) new warnings (-Werror=format-truncation)
>
> Depends what you mean by "support". Are we testing them
> in our build/CI loop? Apparently not :-)

We test some. The Travis loop currently installs the toolchain PPAs for
two of its runs to use:

        - COMPILER_NAME=clang CXX=clang++-3.9 CC=clang-3.9
        - COMPILER_NAME=gcc CXX=g++-5 CC=gcc-5

That said it probably makes more sense to add a rawhide docker image for
testing. Whether it is worth running it on every patch series remains to
be seen as while it might give some advanced warning could it also be
because the bleeding edge distro is broken in some other way?

> Do we fix them?
> Yep, certainly, because bleeding-edge libraries and
> compilers will eventually be standard ones. Do we fix
> them during the release process? Yes, but maybe if
> the fix is very invasive somehow we might prefer to
> postpone to the next release. Do we consider them
> a release-critical bug that we'd spin an extra rc
> for? I don't think so, because (a) for released tarballs
> -Werror is not on by default (b) even for building from
> git you can work around this with -disable-werror
> (c) it's just an accident of timing if a new gcc drops
> 3 weeks before release rather than 3 weeks after, so
> it's always possible that releases will end up being
> built on compilers that warn about things in them.
>
> More generally, I'm not going to go so far as to insist
> that we have a build machine for every flavour of every
> distro -- that would not usefully improve coverage I think.
> Also I'm happy to be ad-hoc about exactly what we test
> (my x86 Linux builds are just "the Ubuntu flavour my
> desktop box happens to be running right now") because
> being less ad-hoc feels like it would be work that
> we don't really need to engage in.
>
> thanks
> -- PMM


--
Alex Bennée