summaryrefslogtreecommitdiff
path: root/content/contribute/_index.md
blob: 59e289ec044418ee5fb337fc4422d90a26fa6f00 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
+++
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).

## 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" %}}Following lines are a snippet of [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).

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
```

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 dev@dpdk.org --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 previous 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 --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.

## Technical Board {#board}
---

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