| layout | title | nav_order | nav_titles | titles_max_depth |
|---|---|---|---|---|
home |
Contributing |
11 |
true |
2 |
There are many ways to contribute to MPTCP in general:
- Reporting bugs
- Testing the development version
- Talking about it on social media, mailing lists, conferences, etc.
- Sending supportive messages to other contributors
- Helping new users on different platforms: mailing lists, IRC, external services
- Asking to enable it by default on services (servers) and devices
- Adding native MPTCP support in apps (or asking app developers to add native MPTCP support)
- Improving this website
- Improving
mptcpd, and tools used to configure MPTCP, e.g. IPRoute2, NetworkManager, etc. - Sponsoring the maintainers (e.g. on GitHub for Matt)
- etc.
And of course, contributing to the Linux kernel itself, see below.
This part is for kernel developers: modifying MPTCP in the Upstream Linux kernel. Patches with new features and bug fixes are of course welcome.
It is easy to build the kernel, the dependences, and start a VM thanks to MPTCP Upstream Virtme Docker. With just one command, you can get a prompt from a VM using the modified kernel or run the whole test suite. For more details, please see this page from our wiki.
{: .note}
Any push to a fork of the mptcp_net-next
repository on GitHub will trigger the CI: look at the Actions tab in the fork
repository to follow the progress, and show the results.
Like many kernel subsystems, patches can be sent to the assigned mailing list ([email protected]), and not via Pull Requests on GitHub. The idea is not to restrict access to people who have a GitHub account, and to have a decentralized system.
Sending patches by email is not difficult, no more than setting up a GitHub account, with the verification of the email address, a new SSH key, etc.
To help with this task, we recommend using b4. After having installed it, you need to either:
- configure the web-endpoint (launching 3 commands)
- or set info about your SMTP server in the git config file
The workflow is then easy: use
b4 prep to
create a new branch, and
b4 send to send
your patches by email.
In short, once b4 has been installed and configured, the workflow looks like:
git switch export # or export-net for fixes
b4 prep -n <new branch name>
# edit your code
git add -p && git commit -s
./scripts/checkpatch.pl -g HEAD ## check the output, fix issues with 'git commit --amend'
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 sendOnce sent, the patches will be tested by our CI. A report will then be posted on Patchwork. See the CI page on our wiki for more details.
Please always include the reason why a patch is needed: we can easily list
the modifications by looking at the patch itself (diff), but understanding why
a modification has been done, why it has been done this way and not another one,
etc. is important context for reviewers and future maintenance. This information
should appear in the commit message.
For more details, please check the kernel doc page.
Do not hesitate to look at the Git history to get some examples.
It is the same as the guidance for Netdev, see their FAQ for more details.
- Designate your patch for a specific tree -
[PATCH mptcp-net]or[PATCH mptcp-next], see the Patch prefixes page for more details. - 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 (from longest to shortest lines).
- Use
checkpatch.pl, e.g../scripts/checkpatch.pl -g HEAD - Use
shellcheckfor the Shell scripts. - Keep the same style as the surrounding code.