[Qemu-devel] QEMU Summit 2018 minutes

[Peter Maydell]

As usual, during this year's KVM Forum we also held the
QEMU Summit, which is where the more active subsystem
maintainers meet up for a discussion of various maintenance
and other project issues. As always, none of this is set-in-stone
decisions; further input and discussion on-list is welcome.


 * Jeff Cody (QEMU system admin) leaving Red Hat but staying on as
   system administrator

   Stefan is the fallback admin and Paolo also has server root access
   for emergencies.

 * Google+ is shutting down, how should we replace it?

   G+ was used to announce QEMU releases and internship opportunities.
   Stefan will set up new accounts on Twitter and Mastodon.  Mike Roth
   will have access for release announcements.

 * QEMU Leadership Committee: Are changes to committee membership
   necessary (it's been 3 years)?

   The Leadership Committee represents QEMU in the Software Freedom
   Conservancy (the legal home for our project).  At the moment no
   urgent changes are necessary, but we're open to suggestions for new
   members.

 * MAINTAINERS "R:" (designated reviewer): should this be open to
   anyone?

   The maintainer still merges patches, but R: people have expressed an
   interest in reviewing patches and should be CCed.  There is debate as
   to what exactly R: means.  R: doesn't imply that the person is a
   maintainer although it is sometimes considered as having authority
   over the code.

   Cornelia Huck will send patch to clarify the exact meaning of R:.  It
   will be up to the maintainer to decide who can be added to R:.

 * Deprecating unmaintained features (devices, targets, backends) in QEMU

   QEMU has a mechanism to deprecate features but there remains a lot of
   old unmaintained code.  Refactoring is hindered by untested legacy
   code, so there is a desire to deprecate unmaintained features more
   often.

   Juan Quintela has volunteered to identify potential features for
   deprecation.

   Do we want a staging/unstaging area (similar to the Linux kernel)?
   General view was "no".

   We should require at least a minimal test for each board; if nobody
   cares enough to come up with one, that board should be deprecated.

   Areas that obviously have users, but no maintainers, are a problem
   (but not one we could think of a solution for, alas).

   Also see the qemu-devel discussion about deprecating code:
   https://lists.nongnu.org/archive/html/qemu-devel/2018-10/msg05828.html.

 * How do we change defaults in QEMU?

   There was some discussion about how we select and change our
   defaults, and how we decide the trade-off between breaking
   some existing users and making the default experience for users
   better. We didn't really come to a conclusion here, so rather than
   try to summarize the arguments I'm going to suggest that interested
   parties bring that discussion to the wider qemu-devel audience
   (or to the weekly QEMU call if that seems a useful venue).

thanks
-- PMM