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

[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 (quintela@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

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

[Daniel P. Berrange]

On Fri, Sep 04, 2015 at 01:24:11PM +0100, Peter Maydell wrote:
> This is a brief writeup of what we discussed at the QEMU Summit 2015
> at KVM Forum last month.

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

FYI, earlier this year the CentOS project started a new effort to
provide CI services to open source infrastructure projects. We have
started using them to CI of all libvirt pieces, virt-manager, and
libguestfs. In our initial discussions they also expressed an
interest in supporting QEMU too.

Essentially they provide a public Jenkins service you can see
here:

    https://ci.centos.org/

There's not much written about this except for this sparse page

  https://wiki.centos.org/QaWiki/CI

IIUC, it is x86 only, but even if it can't do everything QEMU
needs, it might be a useful service to take advantage of for
some parts of QEMU CI.

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

Even if QEMU doesn't provide a backported patch for stable, it would
be desirable to at least provide a formal report giving information
on /when/ a flaw was introduced to QEMU, so downstream consumers can
identify whether they're likely vulnerable or not. I've mentioned
a few times before that libvirt has a simple XML file format + support
tools that can record & publish this kind of metadata in text, html
and xml format. eg this doc

  http://security.libvirt.org/2015/0002.html

In this case we did indeed fix all historic branches since it was
a trivial cherry-pick, but sometimes we just mention the broken-by
commit and not any fixed-by, so it is clear whether the old branch
is vulernable or not. The tools are all open source here

  http://libvirt.org/git/?p=libvirt-security-notice.git;a=summary


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

>From the POV of a contributor I think it would be very attractive to
have such a response confirming whether a proposed patch is conceptually
sane vs crazy. Ultimately contributors can accept that reviewers are
overworked and wait patiently as long as there's indication that their
work is going to be useful to the project. What's depressing is when
you get upto version 10 of a patch series and only then get a response
saying your design is crazy.

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

We should encourage the inclusion of more inline API docs in the header
files to help people understand how the internal infrastructure works,
any time a new internal API is added.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

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

[Fam Zheng]

On Fri, 09/04 13:41, Daniel P. Berrange wrote:
> FYI, earlier this year the CentOS project started a new effort to
> provide CI services to open source infrastructure projects. We have
> started using them to CI of all libvirt pieces, virt-manager, and
> libguestfs. In our initial discussions they also expressed an
> interest in supporting QEMU too.
> 
> Essentially they provide a public Jenkins service you can see
> here:
> 
>     https://ci.centos.org/
> 
> There's not much written about this except for this sparse page
> 
>   https://wiki.centos.org/QaWiki/CI
> 
> IIUC, it is x86 only, but even if it can't do everything QEMU
> needs, it might be a useful service to take advantage of for
> some parts of QEMU CI.

Good to know! Yes, eventually QEMU might need more than one Jenkins instances
to cover different hosts, x86 should be a good start. I'll keep an eye on.

Thanks,

Fam

> 
> > * 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)
> 
> Even if QEMU doesn't provide a backported patch for stable, it would
> be desirable to at least provide a formal report giving information
> on /when/ a flaw was introduced to QEMU, so downstream consumers can
> identify whether they're likely vulnerable or not. I've mentioned
> a few times before that libvirt has a simple XML file format + support
> tools that can record & publish this kind of metadata in text, html
> and xml format. eg this doc
> 
>   http://security.libvirt.org/2015/0002.html
> 
> In this case we did indeed fix all historic branches since it was
> a trivial cherry-pick, but sometimes we just mention the broken-by
> commit and not any fixed-by, so it is clear whether the old branch
> is vulernable or not. The tools are all open source here
> 
>   http://libvirt.org/git/?p=libvirt-security-notice.git;a=summary
> 
> 
> > * 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.
> 
> From the POV of a contributor I think it would be very attractive to
> have such a response confirming whether a proposed patch is conceptually
> sane vs crazy. Ultimately contributors can accept that reviewers are
> overworked and wait patiently as long as there's indication that their
> work is going to be useful to the project. What's depressing is when
> you get upto version 10 of a patch series and only then get a response
> saying your design is crazy.
> 
> > * 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.
> 
> We should encourage the inclusion of more inline API docs in the header
> files to help people understand how the internal infrastructure works,
> any time a new internal API is added.
> 
> Regards,
> Daniel
> -- 
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org              -o-             http://virt-manager.org :|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|
> 

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

[Peter Maydell]

On 6 September 2015 at 03:11, Fam Zheng <famz@redhat.com> wrote:
> On Fri, 09/04 13:41, Daniel P. Berrange wrote:
>> IIUC, it is x86 only, but even if it can't do everything QEMU
>> needs, it might be a useful service to take advantage of for
>> some parts of QEMU CI.
>
> Good to know! Yes, eventually QEMU might need more than one Jenkins instances
> to cover different hosts, x86 should be a good start. I'll keep an eye on.

My view is that actually the non-x86 is more important.
If I had a choice of "CI for x86 only" and "CI for everything
except x86" I'd take the latter. Most developers test the
x86 code in the normal course of writing patches, and
submaintainers test it while submitting pull requests.
It's the other hosts that lack testing and would benefit
from the safety net provided by CI to catch problems
in a more timely manner.

thanks
-- PMM

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

[Stefan Weil]

Am 04.09.2015 um 14:24 schrieb Peter Maydell:
> This is a brief writeup of what we discussed at the QEMU Summit 2015
> at KVM Forum last month.

Thanks a lot for this summary. It is very helpful for those who
could not attend the QEMU Summit.

[...]

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

Part of that infrastructure is the FSF savannah server.
The FSF infrastructure is still used for our mailing lists.

http://savannah.nongnu.org/projects/qemu/ needs
someone who updates the summary. There should be
a link to the official website at least, maybe also a
link to the QEMU article on Wikipedia which is more
up to date.

http://git.savannah.gnu.org/cgit/qemu.git was not updated
for 5 years. Should it be removed? I'd prefer to
have a QEMU git mirror there with automated update.

Just ask me if you need a volunteer who looks after
these issues.

[...]

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

Not so new contributors are also grateful for good
documentation. I'm still searching for best practice
documentation how pull requests can be done.

Regards
Stefan W.

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

[Peter Maydell]

On 6 September 2015 at 07:05, Stefan Weil <sw@weilnetz.de> wrote:
> Part of that infrastructure is the FSF savannah server.
> The FSF infrastructure is still used for our mailing lists.
>
> http://savannah.nongnu.org/projects/qemu/ needs
> someone who updates the summary. There should be
> a link to the official website at least, maybe also a
> link to the QEMU article on Wikipedia which is more
> up to date.
>
> http://git.savannah.gnu.org/cgit/qemu.git was not updated
> for 5 years. Should it be removed? I'd prefer to
> have a QEMU git mirror there with automated update.

I finally got round to this -- I have removed the
savannah repo[*] and download area, and updated the summary
for the project to include a link to the project's
official website.

[*] I opted to remove the repo rather than setting it up
as a mirror, because the Savannah documentation says they
only like to host mirrors for projects which are official
GNU ones, which we are not.

thanks
-- PMM

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

[Stefan Weil]

Am 06.11.2015 um 17:22 schrieb Peter Maydell:
> On 6 September 2015 at 07:05, Stefan Weil <sw@weilnetz.de> wrote:
>> Part of that infrastructure is the FSF savannah server.
>> The FSF infrastructure is still used for our mailing lists.
>>
>> http://savannah.nongnu.org/projects/qemu/ needs
>> someone who updates the summary. There should be
>> a link to the official website at least, maybe also a
>> link to the QEMU article on Wikipedia which is more
>> up to date.
>>
>> http://git.savannah.gnu.org/cgit/qemu.git was not updated
>> for 5 years. Should it be removed? I'd prefer to
>> have a QEMU git mirror there with automated update.
> 
> I finally got round to this -- I have removed the
> savannah repo[*] and download area, and updated the summary
> for the project to include a link to the project's
> official website.
> 
> [*] I opted to remove the repo rather than setting it up
> as a mirror, because the Savannah documentation says they
> only like to host mirrors for projects which are official
> GNU ones, which we are not.
> 
> thanks
> -- PMM


Thank you for this update. I think it will help at least some people.

Stefan

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

[Gonglei]

On 2015/9/4 20:24, Peter Maydell wrote:
> * 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.

  I have another proposal:
If we fix CVEs on master, we'd better have a place (maybe www.qemu.org?)
to describe which stable releases are influenced. In this way, the user can fix these CVEs
easier according to the Qemu versions which they used. Meanwhile, it doesn't have
strong requires that release another stable version.

Regards,
-Gonglei

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

[Peter Crosthwaite]

On Fri, Sep 4, 2015 at 5:24 AM, Peter Maydell <peter.maydell@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 (quintela@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
>