[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Minutes of QEMU Summit 2015 (2015-08-18, Seattle)
From: |
Peter Crosthwaite |
Subject: |
Re: [Qemu-devel] Minutes of QEMU Summit 2015 (2015-08-18, Seattle) |
Date: |
Sun, 6 Sep 2015 11:55:41 -0700 |
On Fri, Sep 4, 2015 at 5:24 AM, Peter Maydell <address@hidden> 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 (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.
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
>
- [Qemu-devel] Minutes of QEMU Summit 2015 (2015-08-18, Seattle), Peter Maydell, 2015/09/04
- Re: [Qemu-devel] Minutes of QEMU Summit 2015 (2015-08-18, Seattle), Daniel P. Berrange, 2015/09/04
- Re: [Qemu-devel] Minutes of QEMU Summit 2015 (2015-08-18, Seattle), Stefan Weil, 2015/09/06
- Re: [Qemu-devel] Minutes of QEMU Summit 2015 (2015-08-18, Seattle), Gonglei, 2015/09/06
- Re: [Qemu-devel] Minutes of QEMU Summit 2015 (2015-08-18, Seattle),
Peter Crosthwaite <=