Submitting Xen Project Patches

How To Generate and Submit a Patch to the Xen Project

The Xen Project team uses Git for its source code management. The current Xen Project development tree is at http://xenbits.xen.org/xen.git; "master" is the branch containing the latest development changesets to pass our automated build and test system.

Generating a patch

---

Here's a recommendation on how to create patches using git, as suggested by the Xen Project maintainers. If you want to use mercurial, please see Submitting_Xen_Patches_-_mercurial.

The instructions on this page use the most common git workflow of branches. Many people find this difficult to work with; one alternative is to use stgit instead; you can find instructions at Submitting_Xen_Patches_with_StGit.

Begin by cloning the git repo from XenProject.org:

$ git clone git://xenbits.xen.org/xen.git xen.git

At this point you should have xenbits set up as the remote repostiory called "origin":

$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
  remotes/origin/stable-4.0
  remotes/origin/stable-4.1
  remotes/origin/stable-4.2
  remotes/origin/staging
  remotes/origin/staging-4.0
  remotes/origin/staging-4.1
  remotes/origin/staging-4.2

This process automatically creates a local branch called master that will track the XenProject.org branch called master.

The branch called staging is the bleeding-edge of commits; this is tested regularly with the xen.org build and regression testing system, and when it pases, is pushed to the master branch. It is suggested to develop patches based on the master branch.

When you want to introduce a change, start by making a new branch based on the most recent change in the master branch:

$ git checkout -b out/trondle-calls master
Switched to a new branch 'out/trondle-calls'

Then edit the source files you want to change. You can see which files have changed by using git status.

When you're done editing, use git add to specify which file changes you want included in the changeset, and then use git commit to make a commit. You will be prompted to make a changset description:

$ git status
# On branch out/trondle-calls
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	modified:   foobar/zot.c
#	modified:   foobar/zot.h
#
no changes added to commit (use "git add" and/or "git commit -a")
$ git add foobar/zot.c foobar/zot.h
$ git commit

Alternatively, you can commit all changes using "git commit -a":

$ git commit -a

foobar: Add a new trondle calls

Add a some new trondle calls to the foobar interface to support
the new zot feature.

Signed-off-by: Joe Smith <joe.smith@citrix.com>

Make as many commits on your new branch as are necessary.

If you want to make a local branch based on staging rather than master (for example, to fix a changeset which has caused the XenProject.org nightly testing to fail), you can do the following:

$ git checkout -b staging remotes/origin/staging
Branch staging set up to track remote branch staging from origin.
Switched to a new branch 'staging'

Then in the commands above, you would use "staging" instead of "master" as the base branch. ...

Signing off a patch

---

All patches to the Xen Project code base must include the the line "Signed-off-by: your_name <your_email>" at the end of the change description. This is required and indicates that you certify the patch under the "Developer's Certificate of Origin" which states:

Developer's Certificate of Origin 1.1

        By making a contribution to this project, I certify that:

        (a) The contribution was created in whole or in part by me and I
            have the right to submit it under the open source license
            indicated in the file; or

        (b) The contribution is based upon previous work that, to the best
            of my knowledge, is covered under an appropriate open source
            license and I have the right under that license to submit that
            work with modifications, whether created in whole or in part
            by me, under the same open source license (unless I am
            permitted to submit under a different license), as indicated
            in the file; or

        (c) The contribution was provided directly to me by some other
            person who certified (a), (b) or (c) and I have not modified
            it.

	(d) I understand and agree that this project and the contribution
	    are public and that a record of the contribution (including all
	    personal information I submit with it, including my sign-off) is
	    maintained indefinitely and may be redistributed consistent with
	    this project or the open source license(s) involved.

Making good patches

---

Patches, if accepted, will turn into commits in the git source tree. There are three people to think about when writing the patch and the comment:

• Reviewers on the mailing list, who are trying to understand what your patch does, if it's correct, and what side effects it will have.
• People skimming through changesets deciding if a patch is important for them to look at for backporting, review, implications on out-of-tree patches, &c.
• Someone in the perhaps distant future, who is trying to understand why the code is the way it is.

Try to make your patches with all of these people in mind. To do this:

Break down your patches

• Each patch should preferably do one logical thing (or one related set of things). The goal is for reviewers to understand the change that each patch is making with a minimum of effort.
• No patch should ever break existing functionality.
• Never fix bugs in one of your patches by changing it in a later patch; go back and change the patch with the bug in it.
• Don't mix clean-up patches (which make things look prettier or move things round but don't change functionality) with code-change patches. Clean-up patches should be clearly marked as having no functional changes.

Write a good description for each patch

• The first line the top of the patch should contain a short description of what the patch does, and hints as to what code it touches
• The description should be useful for both the reviewers and people in the future trying to understand what the patch does. It can be as short as Code cleanup -- no functional changes, or as long as it takes to accurately describe the bug you are trying to solve or the new functionality you are introducing.
• The description should be wrapped to a maximum of 80 columns.

Cc the maintainer of the code you are modifying

• Please always send a copy of the patch to (via CC) the maintainer of the code you are modifying.
• The maintainers are listed in the MAINTAINERS file at the top of the Xen source tree. If no maintainer is listed then there is no need for a CC (if you are modifying code with no maintainer then you might like to consider becoming the maintainer for that piece of code!)
• In addition to CCing the maintainer you should always send patches to (via TO) the xen-devel@lists.xenproject.org mailing list as well.
• To add a CC when sending the mail you can use the --cc option to the git send-email command, or you can do it manually in your MUA.

Sending the patches to the list

---

The xen-devel mailing list is moderated for non-subscribers. It is not mandatory to subscribe but it can help avoid this delay. It is possible to subscribe and then disable delivery in the mailman options so as to avoid moderation but not receive list traffic if that is what you would prefer.

Git send-email

The most robust way to send files is by using the git send-email command. (If you're using mercurial, please see our Submitting_Xen_Patches_-_mercurial).

To do this, first set configure your information:

git config --global sendemail.from "YOUR NAME <user@example.org>"
git config --global sendemail.smtpserver imap.example.org
git config --global sendemail.smtpuser USER
# depending on your config you may also set:
git config --global sendemail.smtpencryption tls

If you don't want to enter password for your SMTP server all the time:

git config --global sendemail.smtppass = PASS

Then check to make sure you have the right patches to be submitted by using git :

$ git log master..
commit 347175ecaba64c324853f004e4860a941b07e5a9
Author: Joe Smith <joe.smith@citrix.com>

foobar: Add new trondle calls

...

Next you need to figure out who (if anyone) you should copy the patches to. To do this you should consult the MAINTAINERS file at the top of the Xen Project source tree. If there is a specific maintainer listed for the area of the code you are modifying then it is best to copy the patches to them. You should always send patches to the xen-devel@lists.xenproject.org mailing list as well.

Once you're sure you have the proper series of patches and know who you are sending it to then you're ready to use git send-email:

$ git send-email --to xen-devel@lists.xenproject.org --cc the.maintainer@example.com master..

--to and --cc say who to send the mail to. master.. will tell it to send all changesets on the current branch *after* (not including) the one marked by master.

NB, emacs users: if you're running this from an emacs shell, this can get tricky, since all of the editors it wants to offer you require a terminal. The best option is probably to enable server mode and then set emacsclient as the default editor.

Tada! You should shortly see your patch series appear in your inbox, and on the xen-devel mailing list (depending on how you've configured it.)

Other useful options include:

• --dry-run will go through all the motions of preparing the patchbomb, but instead of sending a mail, will just output the mails it would have sent. Useful for testing.
• --subject-prefix will allow you to change the prefix from [PATCH] to something else. Examples may include --subject-prefx="PATCH RFC" if you just want to get feedback on a patch series (Request For Comments), or --subject-prefix="PATCH v3" for the 3rd version of your patch series.

Sending Patches Manually

It is strongly recommended to use the git send-email extension discussed above. However it is possible to send a patch manually using your regular mail client.

You should be aware that many mail clients have a tendency to mangle the whitespace of a patch making it impossible to apply. It is highly recommended to read Linux's email-clients.txt for advice on how to avoid this in popular mail clients.

Review, Rinse & Repeat

---

After posting your patches you will hopefully see some response in the form of comments, patch review and eventually commit.

The form of the review may often be quite direct and to the point which may be daunting for some people. However bear in mind that detailed criticism of a patch usually means that the reviewer is interested in your patch and wants to see it go in!

Once you have addressed any review you should normally resend the patch. It is normally expected that you address all review before reposting. This often means code changes in your patch but could also mean simply responding to the review comments explaining you reasoning or giving reasons why something should be the way it is.

When resending a patch you should normally include a note of what has changed since last time in the message. Common practice is to include these notes after your Signed-off-by separated by a triple-dash ("---"). This indicates patch commentary specific to the posting which need not be included in the final changelog (although you should also remember to update the changelog if necessary). You should also including a "V2" (V3, V4 etc) tag in the subject line (if you are using the git send-email command then the --subject-prefix option is helpful here).

If someone replies to your patch with a tag of the form "Acked-by: <Developer>", "Reviewed-by:", "Tested-by:" etc then, assuming you have not completely reworked the patch, you should include these tags in any reposting after your own Signed-off-by line. This lets people know that the patch has been seen and that someone approves of it and also serves to prevent reviewers wasting time re-reviewing a patch which is not significantly different to last time. The developers with commit access also like to see postings with such tags since it means they are likely to be much easier to deal with and commit.

An example of a resend of the example patch from above might be:

Subject: [PATCH v2] foobar: Add a new trondle calls

Add a some new trondle calls to the foobar interface to support
the new zot feature.

Signed-off-by: Joe Smith <joe.smith@citrix.com>
Acked-by: Jane Doe <jane.doe@example.com>

---
Changed since v1:
  * fix coding style
  * be sure to treadle the trondle in the error case.

diff -r 63531e640828 tools/libxc/Makefile
--- a/tools/libxc/Makefile	Mon Dec 07 17:01:11 2009 +0000
+++ b/tools/libxc/Makefile	Mon Dec 21 11:45:00 2009 +0000
...

If you do not get any response to your patch or you got lots of Acked-by's but the patch has not been committed (remember that reviewers and maintainers are busy people too and sometimes things may fall through the cracks) then after some time, perhaps 2-4 weeks (guidelines), you should resend the patch, perhaps including [RESEND] in the subject line to alert people that the last mail was dropped. Before resending it may be worth considering if there is anything you can do to improve the commit message or subject line of your patch to better attract the attention of the relevant people. Remember to include any Acked-by/Reviewed-by which you received in response to the previous post.

What If

---

• Your patch is really big?
  • Break it up into smaller logically distinct patches
  • Example - http://markmail.org/thread/e36vcwk3347de27n
• You have lots and lots of patches? If you are going to generate > 20 patches a week:
  • You might want to host a repository tree that the maintainers can pull from, talk to the maintainers

After your patch is committed

Changes committed to Xen Project by the committers are immediately available in the "staging" branch of the main xen.git tree. They are then automatically tested, and if the tests pass the changes are propagated to the "master" branch.

If your patch turns out to break something you will be expected to respond promptly to help diagnose and fix the problem. If it can't be fixed quickly, your change may be reverted.

How To Generate and Submit a Patch to Qemu-Xen

Xen Project uses QEMU as device model, that is the software component that takes care of emulating devices (like the network card) for HVM guests. Two QEMU trees, both using git for revision control, are currently in use by xen.git:

- qemu-xen-traditional: old and stable tree, only bug fixes are accepted in this tree at the moment;

- qemu-xen: new tree used for development, based on the latest stable branch of Upstream QEMU, that currently is available at qemu git repo. See QEMU Upstream on how to manually build it and use it to run VMs.

New features should be developed again the latest upstream QEMU first, see http://wiki.qemu.org/Contribute/SubmitAPatch, then upon request they can be backported to qemu-xen. Only patches that have been acked and committed to qemu.git are eligible to be backported to qemu-xen. In order to request a backport, send an email to xen-devel@lists.xen.org, specifying the original commit id in qemu.git and the reason why the patch should be backported to qemu-xen.

How to Generate, and Submit a Xen Project Patch to the Linux Tree

Like Xen Project, Linux uses the git SCM. The Linux tree contains documentation on submitting patches, in Documentation/SubmittingPatches, as well as a script (scripts/checkpatch.pl) that ensures your patch is in Linux house style. Running git apply --check on your patch can reveal merge errors.

Patches should be emailed to xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, and any relevant maintainers (which can be found by running scripts/get_maintainer.pl on your patch).