From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 3FBBB5942 for ; Fri, 26 Oct 2018 11:37:57 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Oct 2018 02:37:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,427,1534834800"; d="scan'208";a="100875967" Received: from silpixa00399952.ir.intel.com (HELO silpixa00399952.ger.corp.intel.com) ([10.237.223.64]) by fmsmga004.fm.intel.com with ESMTP; 26 Oct 2018 02:37:54 -0700 From: David Hunt To: dev@dpdk.org Cc: thomas@monjalon.net, john.mcnamara@intel.com, David Hunt Date: Fri, 26 Oct 2018 10:37:41 +0100 Message-Id: <20181026093741.25267-1-david.hunt@intel.com> X-Mailer: git-send-email 2.17.1 Subject: [dpdk-dev] [PATCH] doc/contrib: patch and code in same file X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2018 09:37:57 -0000 Add a paragraph to the patch contribution guide suggesting that developers keep doc updates in the same patch as the code, rather than one big doc update as the final patch in a patch set. Signed-off-by: David Hunt --- doc/guides/contributing/patches.rst | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst index a3d788024..ffeb50436 100644 --- a/doc/guides/contributing/patches.rst +++ b/doc/guides/contributing/patches.rst @@ -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. -- 2.17.1