Re: [PATCH] netmap: support git-submodule build otption

[Daniel P . Berrangé]

On Mon, Oct 07, 2019 at 01:39:30PM +0100, Peter Maydell wrote:
> On Mon, 7 Oct 2019 at 13:36, Markus Armbruster <address@hidden> wrote:
> > If CI of QEMU code isn't useful, then I suspect the QEMU code isn't
> > useful, period.  Giuseppe assures us the netmap QEMU code *is* useful.
> > It followe we better make sure our CI covers it.
> 
> It would be an interesting idea to have a requirement that
> any new library dependency can't be introduced into QEMU
> unless one of the systems we do builds on can be set up
> so the new code is compiled...

Being able to at least compile code successfully is a pretty low bar
to cross in terms of CI, so I think that's reasonable in general.

I would not stop in terms of libraries though. We should document our
broader expectations for CI

Compilation

 - All new code must be compiled in one of[1] our CI systems.
 
   This implies

    - Libraries must be available in some OS we compile for

    - New host architectures must have cross compilers available

    - New OS distro targets must have VM test image support

This is not far off what we unofficially expect already, so
it shouldn't be too distruptive if we formally adopt it as a
mandatory rule.

Testing

 - All significant new features should have either unit or
   functional or integration test coverage

 ... something something something ...

We've not really set any expectations around CI beyond compile
testing thus far. We've got a mix of unit testing & functional
testing in the tests/ dir. We're increasingly getting stuff
added there when major features are added. Making this mandatory
is probably too large a step, but it is likely helpful if we
at least set some recommendations / guidelines to push people
in the direction we want to go longer term.

Regards,
Daniel

[1] Having to say "one of" is not especially great. It would be very nice
    to get to the point where we have either container images or VM images
    and no matter what CI harness(es) we use, they always run with either
    a container or VM image[2]. Even if we have bare metal machines available
    we can still execute actual builds inside containers or VM images so
    everyone uses a consistent environment for everything related to CI.

[2] macOS is a problem/exception here given that we can't legally distribute
    VM images, nor can we provide a cross compiler toolchain. For everything
    else we can make VM/container images though.
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|