User:AnthonyLiguori

About

I'm the QEMU project leader and maintain everything that isn't covered by someone else. I also the release manager for our primary release stream. My main area of expertise is x86 virtualization although I try to review as much as possible. I'm not very familiar with TCG so I typically avoid TCG related patches.

• irc: aliguori
• email: aliguori@us.ibm.com

Features

Features that I'm working on:

• Features/HelperNetworking
• Features/PCIMemoryAPI
• Features/RamAPI

Features that I'd like to one day work on:

• Features/NetDeviceFailover
• Features/GtkDisplayState
• Features/PVCrashDetection
• Features/Usability

Work Flow

Here's how I handle QEMU patches. When you submit a patch, if you follow the steps that complement how I apply patches, there's a much stronger likelihood that your patch will be accepted on the first try :-)

• I have a special mail account that sorts any mail with a '[PATCH' in the subject to a folder NeedsFiltering
• The account also sorts mail with '[PULL]' in the subject to a folder PullRequests
• I frequently go through and cull out replies or patches that are obvious rejects from NeedsFiltering. If I drop a patch here, it's because 1) I'm not the right person to apply it 2) there's an obvious problem and I'll send an email describing the problem.
• After a patch has been on the list long enough (2-7 days usually) so that people can comment, I move the patch to a Patches directory. I try to limit this to batches of 10-20 patches at a time.
• I use git-am to apply the Patches folder. If this fails, it's either because 1) the patch is malformed or 2) there's a merge conflict. If the patch is malformed, I'll send an email saying it's malformed. If the patch is consistently resubmitted in a malformed manner, I'll stop responding. If there's a merge conflict, I'll try to resolve the conflict. If there isn't a trivial resolution, I'll ask for a resubmit to have the original author resolve the merge conflict.
• I do a full build of the tree. I usually have all optional libraries installed and I do not pass any arguments to configure. If the build fails, I'll bisect, remove the offending patches, and notify the author.
• I do some basic sanity testing. This involves booting a few guests, verifying networking works, etc. This is automated with some local scripts.
• I rebase to the latest git sources, and do a thorough review of each patch. I'll potentially drop more patches here but will always send an email explaining the problem.
• Depending on the patches submitted, I do more testing in specific areas that patches cover. I had a wide variety of guests and scripts locally to do this and I choose the set of testing to do based on previous experience of what fails.
• Assuming all goes well, I'll push the patches to the main git tree, and notify the author that the patch has been applied.
• At some point later, I go through accumulated commits, and cherry pick individual bug fixes for the stable branch. For the stable branch, I use a combination of a greater set of local tests and kvm-autotest.