X-Git-Url: http://git.droids-corp.org/?a=blobdiff_plain;f=doc%2Fguides%2Fcontributing%2Fpatches.rst;h=2287835f910d3eb8e4f486c91af027c0357140ab;hb=c06ddf9698e0c2a9653cfa971f9ddc205065662c;hp=4fe9025bd166a8f24412c60c51d5b1aa5a486133;hpb=4aeedc255e5613be6dc65b3c52a6c192d860705f;p=dpdk.git

diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index 4fe9025bd1..2287835f91 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -32,6 +32,29 @@ It is also worth registering for the DPDK `Patchwork <http://dpdk.org/dev/patchw
 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
 -------------------------
@@ -67,6 +90,7 @@ The role of the component maintainers is to:
 * 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.
@@ -129,7 +153,7 @@ Make your planned changes in the cloned ``dpdk`` repo. Here are some guidelines
 * Don't break compilation between commits with forward dependencies in a patchset.
   Each commit should compile on its own to allow for ``git bisect`` and continuous integration testing.
 
-* Add tests to the the ``app/test`` unit test framework where possible.
+* Add tests to the ``app/test`` unit test framework where possible.
 
 * Add documentation, if relevant, in the form of Doxygen comments or a User Guide in RST format.
   See the :ref:`Documentation Guidelines <doc_guidelines>`.
@@ -206,18 +230,21 @@ Here are some guidelines for the body of a commit message:
 
 * 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>
 
@@ -336,7 +363,7 @@ Where the range is a ``git log`` option.
 Checking Compilation
 --------------------
 
-Compilation of patches and changes should be tested using the the ``test-build.sh`` script in the ``devtools``
+Compilation of patches and changes should be tested using the ``test-build.sh`` script in the ``devtools``
 directory of the DPDK repo::
 
   devtools/test-build.sh x86_64-native-linuxapp-gcc+next+shared
@@ -358,12 +385,11 @@ Examples of configs are::
    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)
 
@@ -400,6 +426,10 @@ The appropriate maintainer can be found in the ``MAINTAINERS`` file::
 
    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
@@ -504,4 +534,29 @@ patch accepted. The general cycle for patch review and acceptance is:
 #. 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.
+
+DPDK Maintainers
+----------------
+
+The following are the DPDK maintainers as listed in the ``MAINTAINERS`` file
+in the DPDK root directory.
+
+.. literalinclude:: ../../../MAINTAINERS
+   :lines: 3-