Contributing

Patches with new features and bug fixes are of course welcome.

Patches are shared on the mailing list

Why?

Like many kernel subsystems, patches can be sent to our mailing list ([email protected]), and not via Pull Requests. The idea is not to restrict access to people who have a GitHub account, and to have a decentralised system.

It is easy with b4

Sending patches by emails is not difficult, not more than setting up a GitHub account, send the SSH key, etc. To help with this task, we recommend to use b4. After having installed it, you can prepare your environment with a new Git branch, and either use a web-endpoint or an SMTP server to b4 send your patches (use the --reflect to test that before).

In short, once b4 has been installed and configured, the workflow looks like:

git switch export # or export-net
b4 prep -n <new branch name>
# edit your code
git add -p
git commit -s
./scripts/checkpatch.pl -g HEAD ## check the output
b4 prep --edit-cover # if you have more than one patch
b4 send --reflect # check if the mails you sent to yourself are OK
b4 send

Once sent, the patches will be tested by our CI. A report will be sent on Patchwork. See the CI page for more details.

Commit message

Please always include the reason why this patch is needed: we can easily list the modifications you did by looking at the diff, but understanding why you did that, why this way and not another, etc. is harder to find.

For more details, please check the kernel doc page.

Code style

It is the same as the one of Netdev, see their FAQ for more details.

tl;dr

• Designate your patch to a tree - [PATCH mptcp-net] or [PATCH mptcp-next], see the Patch prefixes page.
• For fixes, the Fixes: tag is required, regardless of the tree
• Don't post large series (> 15 patches), break them up
• Don't repost your patches within one 24h period
• Reverse xmas tree for the variable declaration
• Use checkpatch.pl, e.g. ./scripts/checkpatch.pl -g HEAD

Testing the modifications

CI