+++
title = "Contribute"
weight = "4"
+++

Anyone is welcome to contribute.

The collaboration is based on [git](//git.dpdk.org)
and [emails](//mails.dpdk.org/archives/dev).
Coming patches are listed in [patchwork](https://patches.dpdk.org).

Planned features are listed in the [roadmap](/roadmap/)
and integrated during a [cycle started by a merge window](/roadmap/#cycle).

Bugs are open in [bugzilla](https://bugs.dpdk.org/buglist.cgi?bug_status=__open__&product=DPDK).

Some work synchronization may happen via IRC, on Libera.chat channel #DPDK,
or on [Slack dpdkproject workspace](https://join.slack.com/t/dpdkproject/shared_invite/zt-v6c9ef5z-FqgOAS7BDAYqev_a~pbXdw).

## Licenses {#licenses}
---

Main code is BSD licensed and Linux kernel related parts are naturally licensed under the GPL.

## Get source code {#clone}
---

Read-only access:
```
git clone git://dpdk.org/dpdk
```

Or if git is blocked in your network:
```
git clone http://dpdk.org/git/dpdk
```

The source code can be [browsed online](//git.dpdk.org/dpdk/tree/).

## Contribute by sending patches {#send}
---

{{% alert theme="info" %}}
The following instructions should be enough to start contributing.
Regular contributors should read the full
[contribution guidelines](//doc.dpdk.org/guides/contributing/patches.html).
{{% /alert %}}

Patches should be sent and reviewed via the [mailing list](//mails.dpdk.org/archives/dev).
Be sure [to be registered](//mails.dpdk.org/listinfo/dev).

To prepare a patch, it must be saved with
[git commit](http://www.kernel.org/pub/software/scm/git/docs/git-commit.html).

The title will be clearly visible in the
[git repository](//git.dpdk.org/dpdk/log)
and in the [email archives](//mails.dpdk.org/archives/dev).
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).
Few tags are standardized:
```
Coverity issue:
Bugzilla ID:
Fixes:
Cc: stable@dpdk.org
```

Before sending a patch, be sure that there is no licensing issue.
The commit log must have a *Signed-off-by* line (*--signoff* option).
It certifies that you wrote it and/or have the right to send it.\
For a longer explanation, see the
[Developer Certificate of Origin](http://developercertificate.org).

The patch must be sent with
[git send-email](http://www.kernel.org/pub/software/scm/git/docs/git-send-email.html).
It is automatically or manually prepared in the right format by
[git format-patch](http://www.kernel.org/pub/software/scm/git/docs/git-format-patch.html).
Typical usage is:
```
git send-email -1 --to dev@dpdk.org --cc-cmd devtools/get-maintainer.sh
```

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 first email>
--to dev@dpdk.org --cc-cmd devtools/get-maintainer.sh --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](//patches.dpdk.org/patch/14470).

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 first cover letter.

When sending several patches in a series, a cover letter may explain the global idea:
```
git send-email -3 --to dev@dpdk.org --cc-cmd devtools/get-maintainer.sh
--cover-letter --annotate
```

Shallow threading (*--thread --no-chain-reply-to*) is preferred for patch series.
It should be git's default.

If a patch is for a [stable release](//doc.dpdk.org/guides/contributing/stable.html)
rather than for mainline, please send only to stable@dpdk.org and indicate the target branch
using *--subject-prefix*:
```
git send-email -1 --to stable@dpdk.org --subject-prefix='PATCH 17.11'
```

Example of configuration in *~/.gitconfig*:
```
[sendemail]
	suppressfrom = true
	chainreplyto = false
	confirm = always
	envelopesender = auto
	smtpuser = name@domain.com
	smtpserver = smtp.domain.com
	smtpserverport = 465
	smtpencryption = ssl
[alias]
	fixline = log -1 --abbrev=12 --format='Fixes: %h (\"%s\")%nCc: %ae'
```

## Contribute by testing or reviewing patches {#review}
---

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*.

## Status of patches {#patchwork}
---

Once sent to the mailing list, patches are automatically registered
in [patchwork](//patches.dpdk.org) 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](https://patches.dpdk.org/register).
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](//patches.dpdk.org/project/dpdk/) command line.

## Contribute by finding or fixing bugs {#bugzilla}
---

There is a [bug tracker](https://bugs.dpdk.org) where
anybody can notify a bug to the community, and follow the resolution.

A notification is sent to dev@dpdk.org for every new bug.
The fixes must be sent and discussed on the mailing list.

## Mailing list archives {#archives}
---

The dpdk-dev archives are available via [pipermail](//mails.dpdk.org/archives/dev/),
or via [public-inbox](//inbox.dpdk.org/dev/).

The public-inbox archives can also be accessed via [nntp](nntp://inbox.dpdk.org),
and provide a search engine. For more info, visit the
[help](//inbox.dpdk.org/dev/_/text/help/) page.

## Technical Board {#board}
---

The Technical Board may intermediate in the development process,
as described in the [Technical Board operation](/techboard/).