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 ========= Markus Armbruster Alex Bennée Daniel P. Berrangé Paolo Bonzini Mark Cave-Ayland Alex Graf Stefan Hajnoczi Richard Henderson Thomas Huth Cédric Le Goater Philippe Mathieu-Daudé Peter Maydell Michael S. Tsirkin Kevin Wolf David Woodhouse Agenda ====== Finances -------- - The KVM Forum conference made a small profit; as with last year, we plan to use this to help with the financing of the conference in future years. CI -- - We have an Azure -> AWS CI hosting migration coming up as we have no more Azure credits and we have AWS credits now. - CI is still unreliable. We need to be more proactive at reporting failures. qemu.git maintainers should submit issues when tests are flaky so that test owners and private runner owners are aware of test problems. AI policy --------- - Following the publication of our initial AI policy, there was discussion about whether there had been any initial feedback or if there were tweaks we wanted to make to it. - Generally there didn't seem to have been much feedback so far (from actual developers as opposed to the peanut gallery). The general principle behind the policy is to protect the project from legal risks related to copyright and license status of the output. There was some discussion of whether there were simple useful cases where we would be willing to take AI tool output that was an essentially mechanical transformation with "limited creative content". - There was no consensus in the meeting on whether we should consider this sort of change to the policy now, or whether we should give the initial policy some time, and collect feedback based on that longer term experience before making changes. - There is a patch on the mailing list proposing a change to the policy to allow this kind of "limited creative content" contribution: https://lore.kernel.org/qemu-devel/[email protected]/ - We plan to solicit feedback in spring next year on how the policy has worked out in practice. Release tarballs ---------------- - Our release tarballs are quite large, and 85% of them is just the source of EDK2 which we include as the corresponding source for the EDK2 ROM blobs. This seems a bit silly, since most consumers of the tarball are either: - downstream distros who will want to build their own ROM blobs from the real upstream sources - end users who don't want to build the ROM blobs at all - We could perhaps usefully split the tarballs so that the ROM sources and the ROM blobs are in their own tarballs and only people who need them download them. - Relatedly, it would be nice for the ROM blobs to be trivially regenerable by anybody, rather than the current ad-hoc "some trusted person builds a binary locally and we commit it to git" setup. This should be much easier in these days of containers than it was when we first started committing compiled blobs to git. - However, nothing is fundamentally broken with our current setup, so unless anybody who really wants to do this work is going to step up we probably won't do anything ;-) Shifting styles and incomplete API conversions ---------------------------------------------- - The project has lots of ways of achieving similar things with qdev, QOM, etc. This makes it hard for contributors and reviewers to know how something should be written, or which style to recommend in review. Being asked to change APIs/style is disheartening. This is unlikely to be something we can address easily, but some things to aim for that came up in the conversation: - we should be clear which APIs are legacy and must not be used in new code - we should update the old "unfinished transition" wiki page - In particular, there is no current consensus on QOM casts - Using the cast macros looks the neatest stylistically - But it has a runtime overhead, which is irksome in cases where actually at compile time we can be certain the pointer is of a valid type (e.g. cast to parent type) - Different reviewers put different weight on these factors, causing conflicts about what to prefer. thanks -- PMM
