QEMU Summit Minutes

[Peter Maydell]

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.

(Apologies for the somewhat delayed appearance of these
minutes: I was a bit slow about getting them written up
and circulated for additions/corrections.)


Attendees:

"Peter Maydell" <peter.maydell@linaro.org>
"Gerd Hoffmann" <kraxel@redhat.com>
"Alex Graf" <agraf@csgraf.de>
"Richard Henderson" <richard.henderson@linaro.org>
"Thomas Huth" <thuth@redhat.com>
"Alex Bennée" <alex.bennee@linaro.org>
"Alistair Francis" <alistair.francis@wdc.com>
"Kevin Wolf" <kwolf@redhat.com>
"Michael Roth" <michael.roth@amd.com>
"Paolo Bonzini" <pbonzini@redhat.com>
"Michael S. Tsirkin" <mst@redhat.com>
"Mark Cave-Ayland" <mark.cave-ayland@ilande.co.uk>
"Philippe Mathieu-Daudé" <f4bug@amsat.org>
"Stefan Hajnoczi" <stefanha@redhat.com>


Infrastructure
==============

We had a discussion about various aspects of project infrastructure:

Rackspace used to provide us with a free download quota for qemu.org,
but have recently stopped doing this. We've shifted to Azure, with
OSUOSL as a mirror.

Gitlab are clearly becoming much stricter about the CI time they
allow to both projects and individuals. We should:
 * make efforts to ensure we don't use more CI time than we
   absolutely need to for a run
 * look into increased self-hosting of CI runners and other options

Stefan agreed to ask Software Conservancy what other member projects
are doing.

Follow-ups from Stefan Hajnoczi (not discussed during the summit):

No news on a Conservancy-wide solution for project infrastructure. Samba
uses the GitLab Open Source Program with private runners. LibreHealth
uses a private runner too.

Alex Bennee has successfully signed the QEMU project up for the GitLab
Open Source Program, which grants Ultimate tier features. This includes
50,000 CI minutes per month, 500 GB of transfer per month, and 250 GB of
storage. I have not seen confirmation yet that personal forks of
qemu.git share the CI minutes but Daniel Berrangé, Alex Bennée, and I
believe this should be the case.

There is more infrastructure work to do and I'm unable to find the time
to deal with migrating virtual servers off Rackspace (it costs QEMU
money), to use the FTP mirror that OSUOSL set up for us, etc. If another
regular QEMU contributor wants to help Paolo and me with theses things,
please get in touch!


Mailing List Abuse
==================

We had a lessons-learned retrospective about an incident of
abuse on the mailing list, with two main outcomes:


 * for any mailing list users: if you feel something's not right,
   please do reach out and ping somebody. Don't assume that others
   have necessarily seen the thread and are ignoring it.

 * we're going to look at whether we can adjust some of the
   text in our code-of-conduct and similar documentation to make
   it clearer that it's OK to talk to us about an incident even
   if you're not sure whether it's "significant" enough to be
   labelled "abuse".


Leadership Committee
====================

QEMU's Leadership Committee has two roles:
 * it is the official point of contact for the project's interactions
   with the Software Freedom Conservancy
 * it is the contact point for handling problems raised via
   the project's conflict resolution policy

We do have a few committee members who are no longer as actively
involved in the project as they were when first appointed, so we
have the option to rotate some new people in if we like.
We discussed some possibilities but did not come to a conclusion.
We don't think there's any urgency to appoint a new committee
member. Input on this point is welcome.


Bug Tracking System
===================

We discussed the state of our bug tracker now we've had time
to see how the migration from Launchpad to Gitlab has gone.

At point of conversion we had about ~450 bugs; we're up to
~650 open bugs now. Gitlab doesn't have the same kind of
automated close-stale-bugs machinery that Launchpad did, so
we probably have more stale bugs than we did. There was
no consensus about whether we should be more active/automated
about closing old bugs.


It was noted that it's now harder to CC somebody on a bug
because you can't just cc them on a reply on the mailing list.
We agreed that we should have some way (probably in MAINTAINERS)
for developers to note their gitlab user ID, so it's easier to
find out the right ID to @ to get somebody's attention on a bug.


Security Process
================

As is traditional, we had a somewhat inconclusive discussion
about the project's security process.

The CSV process seems opaque, but no one has really complained or
volunteered to do more point releases, so we're not going to
change anything.

MST raised again the idea that we could help security-issue
raisers identify whether their bug report was in what we
consider to be a security issue or not, with a command line
switch (presumably using "security supported" bit on each
device?). The feedback when this has been raised on the
mailing list in the past was "not the right way to do this";
the mailing list still seems the best venue if more
discussion is required.


KVM Call Slot
=============

The project has a weekly available conference-call slot
where we could in theory discuss any kind of issue that seems
more productively handled via a video call than on the
mailing list. (For instance, perhaps some issues that we
talked about in this Summit meeting could be handled that way
rather than waiting for the KVM Forum date?) However, we don't
in practice make any use at all of the call.

We've had a few good well-focused uses of the call in the past
to work through things that would have taken much longer on
the mailing list (Avi Kivity's initial presentation of
the MemoryRegion API springs to mind).

Making the call more useful would probably involve:
 * having a standard way of writing up proposed items
   for a call discussion
 * making sure the relevant people are actually going to
   join the call (this probably means a longer notice period
   and some effort in actively flagging who is useful to
   be included)

Practical suggestions welcome.


thanks
-- PMM