The development process requires some familiarity with the ``git`` version control system.
Refer to the `Pro Git Book <http://www.git-scm.com/book/>`_ for further information.
+Source License
+--------------
+
+The DPDK uses the Open Source BSD-3-Clause license for the core libraries and
+drivers. The kernel components are GPL-2.0 licensed. DPDK uses single line
+reference to Unique License Identifiers in source files as defined by the Linux
+Foundation's `SPDX project <http://spdx.org/>`_.
+
+DPDK uses first line of the file to be SPDX tag. In case of *#!* scripts, SPDX
+tag can be placed in 2nd line of the file.
+
+For example, to label a file as subject to the BSD-3-Clause license,
+the following text would be used:
+
+``SPDX-License-Identifier: BSD-3-Clause``
+
+To label a file as dual-licensed with BSD-3-Clause and GPL-2.0 (e.g., for code
+that is shared between the kernel and userspace), the following text would be
+used:
+
+``SPDX-License-Identifier: (BSD-3-Clause OR GPL-2.0)``
+
+Refer to ``licenses/README`` for more details.
Maintainers and Sub-trees
-------------------------
* Review patches for the component or delegate the review.
The review should be done, ideally, within 1 week of submission to the mailing list.
* Add an ``acked-by`` to patches, or patchsets, that are ready for committing to a tree.
+* Reply to questions asked about the component.
Component maintainers can be added or removed by submitting a patch to the ``MAINTAINERS`` file.
Maintainers should have demonstrated a reasonable level of contributions or reviews to the component area.
* The text of the commit message should be wrapped at 72 characters.
-* When fixing a regression, it is a good idea to reference the id of the commit which introduced the bug.
- You can generate the required text using the following git alias::
+* When fixing a regression, it is required to reference the id of the commit
+ which introduced the bug, and put the original author of that commit on CC.
+ You can generate the required lines using the following git alias, which prints
+ the commit SHA and the author of the original code::
- git config alias.fixline "log -1 --abbrev=12 --format='Fixes: %h (\"%s\")'"
+ git config alias.fixline "log -1 --abbrev=12 --format='Fixes: %h (\"%s\")%nCc: %ae'"
- The ``Fixes:`` line can then be added to the commit message::
+ The output of ``git fixline <SHA>`` must then be added to the commit message::
- doc: fix vhost sample parameter
+ doc: fix some parameter description
- Update the docs to reflect removed dev-index.
+ Update the docs, fixing description of some parameter.
- Fixes: 17b8320a3e11 ("vhost: remove index parameter")
+ Fixes: abcdefgh1234 ("doc: add some parameter")
+ Cc: author@example.com
Signed-off-by: Alex Smith <alex.smith@example.com>
x86_64-native-linuxapp-gcc+next+shared
x86_64-native-linuxapp-clang+shared
-The builds can be modifies via the following environmental variables:
+The builds can be modified via the following environmental variables:
* ``DPDK_BUILD_TEST_CONFIGS`` (target1+option1+option2 target2)
* ``DPDK_DEP_CFLAGS``
* ``DPDK_DEP_LDFLAGS``
-* ``DPDK_DEP_MOFED`` (y/[n])
* ``DPDK_DEP_PCAP`` (y/[n])
* ``DPDK_NOTIFY`` (notify-send)
git send-email --to maintainer@some.org --cc dev@dpdk.org 000*.patch
+Script ``get-maintainer.sh`` can be used to select maintainers automatically::
+
+ git send-email --to-cmd ./devtools/get-maintainer.sh --cc dev@dpdk.org 000*.patch
+
New additions can be sent without a maintainer::
git send-email --to dev@dpdk.org 000*.patch
#. In addition a patch will not be accepted if it doesn't address comments from a previous version with fixes or
valid arguments.
-#. Acked patches will be merged in the current or next merge window.
+#. It is the responsibility of a maintainer to ensure that patches are reviewed and to provide an ``ack`` or
+ ``nack`` of those patches as appropriate.
+
+#. Once a patch has been acked by the relevant maintainer, reviewers may still comment on it for a further
+ two weeks. After that time, the patch should be merged into the relevant git tree for the next release.
+ Additional notes and restrictions:
+
+ * Patches should be acked by a maintainer at least two days before the release merge
+ deadline, in order to make that release.
+ * For patches acked with less than two weeks to go to the merge deadline, all additional
+ comments should be made no later than two days before the merge deadline.
+ * After the appropriate time for additional feedback has passed, if the patch has not yet
+ been merged to the relevant tree by the committer, it should be treated as though it had,
+ in that any additional changes needed to it must be addressed by a follow-on patch, rather
+ than rework of the original.
+ * Trivial patches may be merged sooner than described above at the tree committer's
+ discretion.
git.droids-corp.org / dpdk.git / blobdiff