Submitting Xen Project Patches
How To Generate and Submit Patches 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/gitweb/?p=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.
|
The instructions on this page use the most common git workflow: aka the patch series is developed on a git branch. Many people find this difficult to work with. There are some alternatives
|
If you want to use mercurial, please see Submitting_Xen_Patches_-_mercurial.
Begin by cloning the git repo from XenProject.org:
$ git clone git://xenbits.xenproject.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 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!).
- You can pipe your patch to the
./scripts/get_maintainer.pltool and it will list the relevant maintainers.
- You can pipe your patch to the
- 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.
Providing a git branch
If you need to send more than one patches (which normally means you're sending a patch series with cover letter), it is recommended to include a branch pointing to your public git repository (if you have one) in your cover letter, so that people can pull directly from that branch.
One option is to fork the GitHub mirror at https://github.com/xen-project/xen into your own project space and push your branch to your own fork and provide a link to that branch.
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.
Note well, 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.)
When sending a series (as opposed to a single patch) it is recommended to preceed it with a "[PATCH 0/N]" mail giving a brief overview of the series. This can be done using the --compose option to git send-email or by sending it from you regular email client and then using the --in-reply-to=<MESSAGE-ID> option (with the contents of message-id header of the 0/N mail) to cause the series to appear as a reply to that message. Note well, that the < and > are a literal part of the message ID (i.e. you should include them).
Other useful options include:
--dry-runwill 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-prefixwill 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 (see also--reroll-count=N).
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 --reroll-count=N option is helpful here, or for older git versions --subject-prefix='PATCH vN').
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 you should:
- Check that the patch has not been applied to the staging branch, since committers do not always send a notification when they apply a patch.
- Consider 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
How to know when a patch has been 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.
After your patch is committed
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 Linux maintainers (which can be found by running scripts/get_maintainer.pl on your patch).
The FreeBSD prject uses svn for it's master source tree, although git clones are also available. Checkout the code from either the svn or the git mirror and remember to always create your patch against the HEAD branch. It can be backported to stable versions afterwards, but it needs to be initially committed to HEAD.
The best way to get your patches reviewed is to use Phabricator, see: https://wiki.freebsd.org/Phabricator and assign them to the relevant maintainer (check MAINTAINERS in the source tree), for Xen related code that would be royger.
How to Generate, and Submit a Xen Project Patch to MiniOS and Unikraft
MiniOS uses the following git tree for development: mini-os.git. Patches are submitted to minios-devel@.
Unikraft uses several git trees under the unikraft namespace for development: unikraft/. Patches are submitted to minios-devel@ and are marked with a UNIKRAFT prefix (or with a library name prefix), such that they can be differentiated from MiniOS patches. A detailed description of the Unikraft convention can be found in the Unikraft base repository unikraft/unikraft.git: CONTRIBUTING.md.
