diff options
Diffstat (limited to 'doc/guides/contributing/patches.rst')
| -rw-r--r-- | doc/guides/contributing/patches.rst | 19 |
1 files changed, 12 insertions, 7 deletions
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst index a3d78802..a64bb036 100644 --- a/doc/guides/contributing/patches.rst +++ b/doc/guides/contributing/patches.rst @@ -28,9 +28,9 @@ The DPDK development process has the following features: * All sub-repositories are merged into main repository for ``-rc1`` and ``-rc2`` versions of the release. * After the ``-rc2`` release all patches should target the main repository. -The mailing list for DPDK development is `dev@dpdk.org <http://dpdk.org/ml/archives/dev/>`_. -Contributors will need to `register for the mailing list <http://dpdk.org/ml/listinfo/dev>`_ in order to submit patches. -It is also worth registering for the DPDK `Patchwork <http://dpdk.org/dev/patchwork/project/dpdk/list/>`_ +The mailing list for DPDK development is `dev@dpdk.org <http://mails.dpdk.org/archives/dev/>`_. +Contributors will need to `register for the mailing list <http://mails.dpdk.org/listinfo/dev>`_ in order to submit patches. +It is also worth registering for the DPDK `Patchwork <http://patches.dpdk.org/project/dpdk/list/>`_ 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. @@ -130,7 +130,7 @@ main repository:: git clone git://dpdk.org/dpdk git clone http://dpdk.org/git/dpdk -sub-repositories (`list <http://dpdk.org/browse/next>`_):: +sub-repositories (`list <http://git.dpdk.org/next>`_):: git clone git://dpdk.org/next/dpdk-next-* git clone http://dpdk.org/git/next/dpdk-next-* @@ -169,6 +169,11 @@ Larger changes that require different explanations should be separated into logi A good way of thinking about whether a patch should be split is to consider whether the change could be applied without dependencies as a backport. +It is better to keep the related documentation changes in the same patch +file as the code, rather than one big documentation patch at then end of a +patchset. This makes it easier for future maintenance and development of the +code. + As a guide to how patches should be structured run ``git log`` on similar files. @@ -281,7 +286,7 @@ in the body of the commit message. For example:: Signed-off-by: Alex Smith <alex.smith@example.com> -`Bugzilla <https://dpdk.org/tracker>`_ +`Bugzilla <https://bugs.dpdk.org>`_ is a bug- or issue-tracking system. Bug-tracking systems allow individual or groups of developers effectively to keep track of outstanding problems with their product. @@ -303,7 +308,7 @@ Patch for Stable Releases ~~~~~~~~~~~~~~~~~~~~~~~~~ All fix patches to the master branch that are candidates for backporting -should also be CCed to the `stable@dpdk.org <http://dpdk.org/ml/listinfo/stable>`_ +should also be CCed to the `stable@dpdk.org <http://mails.dpdk.org/listinfo/stable>`_ mailing list. In the commit message body the Cc: stable@dpdk.org should be inserted as follows:: @@ -504,7 +509,7 @@ If the patch is in relation to a previous email thread you can add it to the sam git send-email --to dev@dpdk.org --in-reply-to <1234-foo@bar.com> 000*.patch The Message ID can be found in the raw text of emails or at the top of each Patchwork patch, -`for example <http://dpdk.org/dev/patchwork/patch/7646/>`_. +`for example <http://patches.dpdk.org/patch/7646/>`_. Shallow threading (``--thread --no-chain-reply-to``) is preferred for a patch series. Once submitted your patches will appear on the mailing list and in Patchwork. |