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 that I'd like to one day work on:
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.