User:AnthonyLiguori: Difference between revisions

From QEMU
No edit summary
 
Line 1: Line 1:
== About ==
== About ==


I'm a QEMU maintainer focused on virtualization support.  My main area of expertise is x86 although I try to review as much as possible.  I'm not very familiar with TCG so I typically avoid TCG related patches.
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
* irc: aliguori

Latest revision as of 00:04, 20 May 2013

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.