qemu-devel
[Top][All Lists]
Advanced

[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
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]