QEMU Summit Minutes

* QEMU Summit Minutes
@ 2019-11-25 14:34 Peter Maydell
  0 siblings, 0 replies; 3+ messages in thread
From: Peter Maydell @ 2019-11-25 14:34 UTC (permalink / raw)
  To: QEMU Developers

As usual, we held a QEMU Summit meeting at KVM Forum.
This is an invite-only meeting for the most active maintainers
and submaintainers in the project, and we discuss various
project-wide issues, usually process stuff. We then post
the minutes of the meeting to the list as a jumping off point
for wider discussion and for those who weren't able to attend.

Attendees:
Peter Maydell
Kevin Wolf
Richard Henderson
Markus Armbruster
Gerd Hoffmann
Eduardo Habkost
Laurent Vivier
Mike Roth
Alex Bennée
David Gibson
Stefan Hajnoczi
Thomas Huth
Cornelia Huck
Paolo Bonzini
Daniel Berrangé
Aleksandar Markovic
Paul Durrant
Juan Quintela

1. QEMU Leadership Committee

The Leadership Committee represents QEMU in the Software Freedom
Conservancy (the legal home for our project). Generally it doesn't
have much to do as we luckily don't have active legal problems :-)
One of the rules for the committee is that it mustn't have more
than two members employed by the same company at once; since IBM
acquired Red Hat that put them over the two-person limit and we
needed to adjust the membership. Mike Roth has now stepped down,
and Alex Bennée has agreed to take up the now-vacant seat.
I'd like to thank Mike for his past work and Alex for agreeing
to take on the role.
(The full list of members is at https://wiki.qemu.org/Conservancy)

2. Sharing qemu.git/master maintainership duties

Something I've talked about on the list before is that I'd like to
move away from doing all the work on merging pull requests and
wrangling releases, but we hadn't made much forward progress on this.
The concrete next thing we need to do is move the testing of merges
away from my ad-hoc setup onto a proper CI system.

Markus Armbruster told us that Red Hat is willing to help set up the
generic parts of the CI plus builders for the host architectures
they care about. Host architecture/OS maintainers will need to keep
other builders running and triage failures.  Red Hat is interested in
x86, ppc, s390, and aarch64.

There was a discussion of various possible approaches, mostly
centring on patchew vs gitlab, with the consensus being that
we should prefer gitlab unless the issues with running on non-x86
hosts turn out to be unsolvable.

Mike Roth noted that CI/release handling for stable releases is separate
from the testing done for mainline, and the stable release process is
separate from the regular release process. Once we have working
CI on mainline we should look at using the same mechanisms for stable.

I've written up a draft requirements wiki page for the CI work:
 https://wiki.qemu.org/Requirements/GatingCI

3. QEMU Security

We had a general discussion about our current security process,
and various people raised pain points/issues. Most of them were
familiar from the discussion of the previous year...

Daniel Berrangé noted that CVEs are hard to spot upstream.  Some
commits may not contain CVE numbers because the CVEs were filed after
the commit - this makes it hard to be sure your QEMU build is
secure. We could do a better job of documenting project security
issues, as libvirt does.

I (re)raised my view from last year, which is that upstream QEMU
doesn't provide timely stable releases when security issues are
fixed. The practical effect of this is that users are forced to use
distro releases of QEMU, unless they want to take on the large burden
of tracking CVEs and the commits that fix them and rolling their own
versions of QEMU. I think that it would be better as a project for our
users if we provided releases with security fixes (it's what most
projects do), but in practice we don't seem to have anybody who cares
enough to put in the work that would require.

The suggestion was made that we should document on the website what
the purpose/scope of our stable releases is.

4. GPL circumvention via plugins and out-of-process devices

Markus Armbruster noted that we now have several "plugin" like
interfaces, and these raise a risk of a situation where the GPL is
circumvented via proprietary features.  How to resist circumvention?
(Plugin-like interfaces include the "modules" system we have already,
the new "TCG plugins", vhost-user, and usb-redir.)

There was a wide-ranging discussion, and overall we seemed to be mostly
in consensus that the philosophy the project takes is broadly:
 * it's obviously not possible to technically prevent license
   circumvention if somebody really wants to do it
 * we aim to make it require an obvious "this is not something
   we intended you to do" step across a red line
 * we don't want to have the project end up stuck with the pain
   of maintaining a stable ABI while out-of-tree plugin/device/etc
   implementations get all the benefits
 * we'd like to catch end-user accidental attempts to load
   a module/TCG plugin/etc from a mismatched version in a friendlier
   way than just crashing
 * depending on the exact situation, there might be different
   approaches to providing the 'red line', e.g.
    - specifying a clearly limited-purpose API with version-checking
    - including checks that a module/plugin was built against the
      same git hash as the QEMU binary it's used with

Since we now have an increasing number of these 'external interfaces',
Daniel Berrangé agreed to write up some guidelines explaining the
general philosophy.

5. git pull request workflow when there are multi-level sub-maintainers

This one we probably want to discuss on the mailing list, because
it was submitted by Cornelia Huck, but she had to leave the meeting
before we got to this agenda item.

Some starter points from the meeting discussion:

 * most people present seemed to be using the "we don't have
   multilevel submaintainers, usually rebase before sending pull" flow

 * as the person doing merges of pullreqs, I don't much care
   what the submaintainer's workflow is, as long as it doesn't
   produce a deeply weird git commit graph when merged, and is
   capable of handling "this fails tests, please fix" bounces
   (which in the common workflow are dealt with via 'squash
   in fix and rebase'), preferably without breaking bisection

 * Kevin Wolf notes that although they never made an explicit decision,
   in practice the block layer team has stopped doing multilevel
   submaintainers and instead just has several people sending separate
   pullrequests directly. In the common case, single level is just much
   easier because it requires less coordination (especially when a v2
   pull request is needed).

 * Alex Bennée noted that the Linux kernel development process tends
   to avoid rebasing, on the theory that testing is wasted when trees
   are rebased. However he thought that the distributed testing model
   of Linux gives more weight to the status of a "tested tree branch",
   wherease for QEMU how applicable this is depends on how much
   testing is done at different levels on the PR tree. For us
   if the maintainer re-runs the tests on re-base it is less
   of an issue, as it's unlikely many other people will have done
   much testing on that tree anyway.

 * Various people noted that the 'rebase invalidates testing' idea
   has holes in it of various kinds anyway.

6. Mentorship

Aleksandar Markovic wanted to raise the topic of mentorship as
a skill for QEMU maintainers. There was a general discussion of
things we're doing already (eg the GSOC and Outreachy internships,
the 'bitesized tasks' wiki page) and things we could do.

Aleksandar said he'd write up and share mentoring advice with the
community.
Stefan said he had a link to QEMU internship talk video.

7. Documentation pipeline discussion

Alex Bennée said it would be nice to get our docs (user and
development) being regularly re-generated and nicely hosted on our
infrastructure.  There was general agreement; the blocker has always
been that this requires somebody with interest in the documentation,
time to work on it and also access to the VM which runs out website.

Stefan agreed to create a docs container image to give us a
starting point which we can iterate on. (He's now posted some
patches to the list which do this; thanks!)

We intend to move to rST and Sphinx.  Perhaps the biggest obstacle is
converting qemu-doc.texi and its prerequisites, such as the Texinfo
embedded into the *.hx, and the Texinfo generated from QAPI schema doc
comments.

Markus said he would be okay with making the QAPI doc generator
generate rST instead of Texinfo, but lacked the bandwidth to do it
himself.

Paolo said he'd investigated a document flow where we (temporarily)
had a tool (Pandoc) which converted rST to Texinfo so we could
gradually convert parts of qemu-doc.texi to rST while still building
that document with Texinfo.

I said that I would prefer it if we could avoid the sort of
long-drawn-out changeover that that approach implies, and that
although there is a fair amount of text to convert in qemu-doc,
it would be better to try to just make it a release goal to
do the conversion. If we start with a skeleton of the new
documentation, we can then convert portions of the documentation.
During the transition we'll effectively have two 'manuals'
on the same topic with some info in one and some in the other.

thanks
-- PMM

^ permalink raw reply	[flat|nested] 3+ messages in thread