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 (quint...@redhat.com), 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
