Re: [Qemu-devel] Minutes of QEMU Summit 2015 (2015-08-18, Seattle)

[Daniel P. Berrange]

On Fri, Sep 04, 2015 at 01:24:11PM +0100, Peter Maydell wrote:
> This is a brief writeup of what we discussed at the QEMU Summit 2015
> at KVM Forum last month.

> * Continous integration
>  * Another perennial issue :-)
>  * Buildbot is broken and unmaintained: will probably go down soon
>  * The future here is patchew, being developed by Fam Zheng (and
>    it is the future largely because it has a volunteer to work
>    on it, unlike buildbot).
>  * RedHat might have some available resource to help us with
>    our CI efforts; we'll check.
>  * Being able to test bootup of images would be really useful;
>    Alex Graf has a setup he uses for s390/ppc images, and could
>    make machines available for CI use. Again the issue really is
>    having somebody to maintain and care for the images and tests.

FYI, earlier this year the CentOS project started a new effort to
provide CI services to open source infrastructure projects. We have
started using them to CI of all libvirt pieces, virt-manager, and
libguestfs. In our initial discussions they also expressed an
interest in supporting QEMU too.

Essentially they provide a public Jenkins service you can see
here:

    https://ci.centos.org/

There's not much written about this except for this sparse page

  https://wiki.centos.org/QaWiki/CI

IIUC, it is x86 only, but even if it can't do everything QEMU
needs, it might be a useful service to take advantage of for
some parts of QEMU CI.

> * Security process
>  * We've improved and documented our security process over the last
>    year or so, but it could still be improved.
>  * Big problem -- we fix CVEs on master, but we don't provide a stable
>    release with security fixes until the next time we would have
>    done a release anyway; this can mean we go for months without
>    any available stable release without known security issues.
>  * We could do a stable release immediately we have a CVE, but this
>    is obviously more work for our stable maintainer (Michael Roth).
>    We might get a few CVEs a cycle, though obviously it varies.
>  * Proposal to mitigate this:
>    + go to one full stable release per cycle, rather than the
>      theoretical two per cycle we currently try for (ie one per
>      4 months, not per 2 months)
>    + somebody else to do the backport-patch-to-stable (Stefano
>      Stabellini volunteered for this since he has to already for
>      anything which affects Xen)
>    + the intermediate stable releases for security issues would only
>      contain the CVE fixes, not be a full "flush the stable queue"
>      release
>    + stable maintainer to be looped in pre-disclosure date so
>      there is good notice of CVE fixes rather than it being an
>      unpleasant surprise
>    + sychronize disclosure dates for CVEs that are reported close together
>    + categorize reported vulnerabilities into "moderate or important:
>      goes through disclosure process and gets stable release" vs
>      "minor: no delayed disclosure, no stable release" to avoid
>      invoking the machinery for the truly trivial (eg the rash of
>      'vulnerable to malicious incoming migration data' bugs we had
>      a while back)

Even if QEMU doesn't provide a backported patch for stable, it would
be desirable to at least provide a formal report giving information
on /when/ a flaw was introduced to QEMU, so downstream consumers can
identify whether they're likely vulnerable or not. I've mentioned
a few times before that libvirt has a simple XML file format + support
tools that can record & publish this kind of metadata in text, html
and xml format. eg this doc

  http://security.libvirt.org/2015/0002.html

In this case we did indeed fix all historic branches since it was
a trivial cherry-pick, but sometimes we just mention the broken-by
commit and not any fixed-by, so it is clear whether the old branch
is vulernable or not. The tools are all open source here

  http://libvirt.org/git/?p=libvirt-security-notice.git;a=summary


> * Review
>  * Patch review workload remains an issue for many submaintainers.
>  * Patches not getting reviewed promptly is dispiriting, especially
>    for new contributors.
>  * One suggestion for this is an approach described by Sarah Sharp
>    in this blog post:
>     http://sarah.thesharps.us/2014/09/01/the-gentle-art-of-patch-review/
>    The general idea is to split review into three phases, where the
>    first phase is just a "is the idea behind this patch good?" with a
>    quick yes/no answer, and (if the answer is 'yes') to send a mail saying
>    so and that the patch is on your to-review queue.

>From the POV of a contributor I think it would be very attractive to
have such a response confirming whether a proposed patch is conceptually
sane vs crazy. Ultimately contributors can accept that reviewers are
overworked and wait patiently as long as there's indication that their
work is going to be useful to the project. What's depressing is when
you get upto version 10 of a patch series and only then get a response
saying your design is crazy.

> * Better documentation for new contributors
>  * Poor documentation of design/internals can be a barrier to
>    new contributors.
>  * We have improved here, but we have to improve more.
>  * Missing documentation includes how-to style information on tasks
>    like 'adding a new device' or 'new target frontend', etc.

We should encourage the inclusion of more inline API docs in the header
files to help people understand how the internal infrastructure works,
any time a new internal API is added.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|