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

[Peter Maydell]

This is a brief writeup of what we discussed at the QEMU Summit 2015
at KVM Forum last month.

* Participants

Markus Armbruster
Paolo Bonzini
Luiz Capitulino
Andreas Färber
Alexander Graf
Eduardo Habkost
Stefan Hajnoczi
Richard Henderson
Gerd Hoffmann
Edgar E. Iglesias
Bastian Koppelmann
Peter Maydell
Juan Quintela
Michael Roth
Amit Shah
Stefano Stabellini
Michael S. Tsirkin
Alex Williamson
Kevin Wolf

* Software Freedom Conservancy
  QEMU has become a Software Freedom Conservancy Project.
  They do the accounting and hold money for us.
  Hold our assets; for instance the qemu-project.org domain name
   will be transferred to them soon.
  Help with lawyers, process, trademarks, .... if necessary
   (all at our request; they don't do stuff unless we ask them to).
  The interface to SFC is the QEMU Leadership Committee (current
   members: Paolo Bonzini, Andreas Färber, Alexander Graf, Stefan Hajnoczi,
   Peter Maydell, Mike Roth)

* Infrastructure Issues
 * Wiki & git & ... hosting
   We're currently hosted for free on OSL at OSU, but we need
   somebody who is willing to do the system administration work
   for the VM which runs our git, wiki, etc.
   We need to find someone who wants to do the job.  It doesn't need to
   be a lot of work, but there will be an initial setup cost.
   Stefan will send an email to qemu-devel describing the things that
   are needed and asking for a volunteer.
 * We should consider transitioning to some hosted service that
   doesn't require sysadminning, but this also would benefit
   from a volunteer to help.

* 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.

* 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)

* Better advertising of the cool stuff we do in QEMU
 * How can we give more visibility of what we have done in each Release?
   We do a changelog, but this is not necessarily widely read.
 * Proposals:
  + to do small videos showing what we have done on each release (Amit)
  + Post one video from KVM Forum each week on Google Plus (Stefan)
  + Give small techinical hangouts when there is a new feature (Stefan)
  + The QEMU Advent Calendar was very popular; we could consider some
    variation on this idea for releases.

* KVM Call
 * There hasn't been a call for the previous three months or so.  Is there
   anything that we can do to have more calls?
 * Consensus was that the call has evolved over time, and is not as
   needed these days (some discussion has migrated to KVM Forum, for
   instance), but that it is nice to retain it.
 * Discussion about when to send the call for agenda.  Conclusion is that
   there is going to be a Call for Agenda always open.  Juan will send a
   Call for Agenda just after one Call is done.
   Call would be cancelled on monday night if there are no topics.
 * If there are problems with timing of the call, or we have to setup a
   new one, just let Juan know (address@hidden), and he can probably
   arrange something.

* 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.
   It's not necessarily going to solve everything, but maintainers who
   are worried that they're not doing review quickly enough might like
   to try it out.

* 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.

thanks
-- PMM