Get the Code
git clone git://dpdk.org/dpdk
If Git Is Blocked on Your Network
git clone http://dpdk.org/git/dpdk
Ways to Contribute
Following lines are a snippet of contribution guidelines.
To prepare a patch, it must be saved with git commit.
The title will be clearly visible in the git repository and in the email archives. So it is important to make it short and clear for quick reading and searches. Prefixes like “mk:”, “mem:” or “pci:” make it easy to read.
The email title must begin with [PATCH] to distinguish it among discussions.
There must be details in the commit log, explaining what was the problem and how it is fixed.
When fixing a regression, it is a good idea to reference the id of the commit which introduced the bug (see fixline alias below).
Before sending a patch, be sure that there is no licensing issue. The commit log must have a Signed-off-by line (–signoffoption). It certifies that you wrote it and/or have the right to send it.
For a longer explanation, see the Developer Certificate of Origin.
git send-email -1 --to firstname.lastname@example.org
If a previous version of the patch has already been sent, a version number and changelog annotations are helpful:
git send-email -1 -v2 --annotate --in-reply-to <Message-ID of the previous patch> --to email@example.com --cc <everybody discussing the patch>
Annotations take place after the 3 dashes and should explicit what has changed since the previous version.
The Message-ID can be found in the email header of the previous patch or in its patchwork page.
In the case of a bug reported on the mailing list, the patch should be a reply to the bug report.
An updated patchset should be a reply to the previous cover letter.
When sending several patches in a series, a cover letter may explain the global idea:
git send-email -3 --to firstname.lastname@example.org --cover-letter --annotate
Shallow threading (–thread –no-chain-reply-to) is preferred for patch series. It should be git’s default.
Example of configuration in ~/.gitconfig:
[sendemail] suppressfrom = true chainreplyto = false confirm = always envelopesender = auto smtpuser = email@example.com smtpserver = smtp.domain.com smtpserverport = 465 smtpencryption = ssl [alias] fixline = log -1 --abbrev=12 --format='Fixes: %h (\"%s\")%nCc: %ae'
Patches are applied in the git repository when it becomes clear that they are well written and do the right things.
Test reports and reviews help a lot in the process. Such contributions are marked with flags Tested-by, Reviewed-by or Acked-by.
Once sent to the mailing list, patches are automatically registered in patchwork with status “New”. So they are visible in the default view (filter “Action Required”).
Access to management of his own patches is granted after registration. The status may be manually updated to “RFC”,“Changes Requested”, “Superseded” or “Rejected”. After sending a new version of a patch, developers should set the previous patch as “Superseded”. When a patch is applied, it is set to “Accepted”.
Patchwork can also help to download patches individually or bundled.
Most of the patchwork actions can be done with a pwclient command line.
There is a bug tracker where anybody can notify a bug to the community, and follow the resolution.
A notification is sent to firstname.lastname@example.org for every new bug. The fixes must be sent and discussed on the mailing list.