On Fri, Sep 4, 2015 at 5:24 AM, Peter Maydell <peter.mayd...@linaro.org> wrote: > 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.
We need to stop chasing acks from all the arch maintainers when you touch target-*. Change patterns should be re-viewable by core maintainers. Regards, Peter > * 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 >
