KVM Forum - save the date is out, cfp will follow later this week - abstracts due in 6wks, 2wk review period, notifications by end of May Improving process to scale project - Trivial patch bot - Sub-maintainership Trivial patch monkeys^Wteam - small/simple patches posted can fall through the cracks (esp. for areas that aren't well maintained) - patches should be simple, easy to review ( - aiming to gather a team, so that the position can rotate - patch submitter can rest assured - Stefan and possibly Mike Roth are volunteering to get this started - Cc: qemu-trivial@xxxxxxxxxx to send patches to the Trivial patch monkey - details here: http://wiki.qemu.org/Contribute/TrivialPatches Sub-maintainership - have MAINTAINERS file - need to add git tree URLs - needs another pass to make sure there are no missing subsystems - make it clearer how maintained the subsystems are - adding a wiki page to show how to become a subsystem maintainer - one valuable step...write testing around the subsystem - means you've had to learn the subsystem (builds expertise) - allows for regression testing the subsystem (esp. validating new patches) - sub-maintainers sometimes disappear - can add another maintainer - actively poke the maintainer when patches are languishing - if you're going to be away, be sure to let list or backup know - systematic patch tracking would help, patchwork doesn't quite cut it - who receives pull request - list + blue swirl/aurelien for tcg, anthony picking up plenty of other bits - infrastructure subsystems (qdev, migration, etc..) - big invasive changes done externally, effective flag day for full merge - subsystem localized change (e.g. vmstate fix for a specific device) maintainers can work it out, be sure to have both - facilitating patch review and hopefully improving subsystem over time kvm-autotest - roadmap...refactor to centralize testing (handle the xen-autotest split off) - internally at RH, lmr and cleber maintain autotest server to test branches (testing qemu.git daily) - have good automation for installs and testing - seems more QA focused than developers - plenty of benefit for developers, so lack of developer use partly cultural/visibility... - kvm-autotest team always looking for feedback to improve for developer use case - kvm-autotest day to have folks use it, write test, give feedback? - startup cost is/was steep, the day might be too much handholding - install-fest? (to get it installed and up and running) - buildbot or autotest for testing patches to verify building and working - one goal is to reduce mailing list load (patch resubmission because they haven't handled basic cases that buildbot or autotest would have caught) - fedora-virt test day coming up on April 14th. lucas will be on hand and we can piggy back on that to include kvm-autotest install and virt testing - kvm autotest run before qemu pull request and post merge to track regressions, more frequent testing helps developers see breakage quickly - qemu.git daily testing already, only the "sanity" test subset - run more comprehensive "stable" set of tests on weekends - one issue is the large number of known failures, need to make these easier to identify (and fix the failures one way or another) - create database and verify (regressions) against that - red/yellow/green (yellow shows area was already broken) - autotest can be run against server, not just on laptop - how to do remote client display testing (e.g. spice client) - dogtail and LDTP - graphics could be tested w/ screenshot compares - WHQL testing automated as well -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
