summaryrefslogtreecommitdiff
path: root/content/contribute/_index.md
diff options
context:
space:
mode:
Diffstat (limited to 'content/contribute/_index.md')
-rw-r--r--content/contribute/_index.md165
1 files changed, 165 insertions, 0 deletions
diff --git a/content/contribute/_index.md b/content/contribute/_index.md
new file mode 100644
index 0000000..418fd85
--- /dev/null
+++ b/content/contribute/_index.md
@@ -0,0 +1,165 @@
++++
+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/).
+
+Focus is on next version in git *HEAD*. There is no maintenance of previous versions.
+
+## 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/).