devguide: doc from behavior changes needs ticket #

If a commit introduces code that changes Suricata behavior, the related
documentation changes should go in a separate commit, but refer to the
same ticket number.
This reduces the chances of said changes being lost if there are backports
while still keeping the backporting process a bit less bulky, for each
commit.

Related to
Task #6568

diff --git a/doc/userguide/devguide/contributing/code-submission-process.rst b/doc/userguide/devguide/contributing/code-submission-process.rst
index 99ac93d5e2014569262efaa3d3e1b6a808dfc496..e6a0f2fd33c80c9c843f5d70bef50beb82423c05 100644 (file)
--- a/doc/userguide/devguide/contributing/code-submission-process.rst
+++ b/doc/userguide/devguide/contributing/code-submission-process.rst
@@ -9,9 +9,12 @@ Commits
 #. Commits need to be logically separated. Don't fix unrelated things in one commit.
 #. Don't add unnecessary commits, if commit 2 fixes commit 1 merge them together (squash)
 #. Commits need to have proper messages, explaining anything that is non-trivial
-#. Commits should not, at the same time, change, rename and/or move code. Use separate commits
-     for each of this, e.g, a commit to rename files, then a commit to change the code.
-#. Documentation updates should be in their own commit (not mixed with code commits)
+#. Commits should not, at the same time, change, rename and/or move code. Use
+   separate commits for each of this, e.g, a commit to rename files, then a commit
+   to change the code.
+#. If your code changes or adds new behavior, add the related documentation
+   updates in their own commit, but make sure to add the same ticket number to
+   both commit messages.
 #. Commit messages need to be properly formatted (check the example further
      below in this section):
       * Meaningful and short (50 chars max) subject line followed by an empty line