Submitting Patches

Xen Project patches are submitted by email to the xen-devel mailing list. This page covers the essentials. For deeper background, see the full patch submission reference at xenbits.

Before you start

Read the CONTRIBUTING, COPYING, and CODING_STYLE files in the repository you are patching. Each sub-project may have additional requirements.

Every patch must include a Signed-off-by line, certifying it under the Developer Certificate of Origin. Add it with git commit -s. The email address must reflect the copyright holder — use your employer’s address if the work was done on company time.

Writing a good patch

Title: One line, with a prefix indicating the area of code (e.g. xen/x86:, tools:, docs:). Keep it short and descriptive.

Description: Explain why the change is needed, not just what it does. Wrap at 80 columns.

Changelog (v2+): When resending a revised patch, put a summary of changes after the --- line. This appears in the email but not in the commit.

For patch series, include a cover letter explaining what the series achieves and why. See the xenbits reference for cover letter guidance.

Subject prefix

Use the canonical prefix for the repository you are patching:

Repository

Subject prefix

Mailing list

xen.git

XEN PATCH

xen-devel@

osstest.git

OSSTEST PATCH

xen-devel@

xtf.git

XTF PATCH

xen-devel@

xenalyze.git

XENALYZE PATCH

xen-devel@

livepatch-build-tools.git

LIVEPATCH-BUILD-TOOLS PATCH

xen-devel@

mini-os.git

MINI-OS PATCH

minios-devel@

unikraft/*.git

UNIKRAFT PATCH

minios-devel@

Set the default prefix for a repository once:

git config --local format.subjectPrefix "XEN PATCH"

Common modifiers: prefix with RFC for patches sent for discussion only; append RESEND if chasing a review; append for-4.21 after a feature freeze to indicate the target release.

The workflow

1. Create patches

git format-patch --reroll-count=2 --thread --cover-letter \
    -o ../patches/feature-v2 -2

Always use --thread and --cover-letter for series — automated tooling on xen-devel requires them. For a single patch, omit --cover-letter.

2. Add maintainer CCs

./scripts/add_maintainers.pl -d ../patches/feature-v2

This reads MAINTAINERS and inserts the correct CC lines. Follow the instructions it prints.

Warning

Do not use add_maintainers.pl for security patches — it will add the public list. Use --suppress-cc=all and send only to security@xenproject.org.

3. Send

git send-email --to xen-devel@lists.xenproject.org \
    ../patches/feature-v2/*.patch

Use --dry-run to preview the emails before sending. See the git send-email docs for setup instructions (SMTP server, credentials).

After submitting

Address all review comments before resending. Rebase against the current development tree first. Use --reroll-count=N to increment the version number, and carry forward any Reviewed-by or Acked-by tags that are still applicable.

If you have had no response after five business days, resend with this phrase at the top of your reply:

Patch escalation: no response for X days

Commits appear first in the staging branch of xen.git. Check there before resending, as committers do not always send a notification.

See Code Review for more on the review process and what the review tags mean. See Patch Submission Reference for detailed reference material: commit message guidance, *-by tag definitions, cover letter contents, add_maintainers.pl options, and more.

Other repositories

Some Xen sub-projects use different workflows: