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