Mirror/frr
0
0
Fork 1
mirror of https://github.com/FRRouting/frr.git synced 2025-04-30 05:27:16 +02:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

doc: add commit message guidelines to the dev guide

Browse source 
Signed-off-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
This commit is contained in:
Jafar Al-Gharaibeh 2025-04-14 22:35:53 -05:00
parent 3da1473093
commit 5d49e40b83
1 changed files with 60 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

65
doc/developer/workflow.rst
View file

@ -354,15 +354,70 @@ This helps to automatically generate human-readable changelog messages.
Commit Guidelines
-----------------
There is a built-in commit linter. Basic rules:
Commit messages must have a title and optionally a detailed description.
- Commit messages must be prefixed with the name of the changed subsystem, followed
The commit title is a short summary of the commit. The following rules apply:
- Must be no more than 72 characters.
- Must be prefixed with the name of the changed subsystem, followed
by a colon and a space and start with an imperative verb.
`Check <https://github.com/FRRouting/frr/tree/master/.github/commitlint.config.js>`_ all
the supported subsystems.
- Should not end with a period.
- Should be a complete sentence.
- Should "make sense" when used with release changelog.
- Think of the end-users reading it and write the title to them.
- FRR maintainers should not need to rewrite the message to explain
your work to end-users on your behalf.
`Check <https://github.com/FRRouting/frr/tree/master/.github/commitlint.config.js>`_ all
the supported subsystems.
Example good commit titles:
- Commit messages must not end with a period ``.``
.. code-block:: console
lib,bgpd: clean up clang warnings
babeld: convert all code to use our code formatting rules
doc: add commit message guidelines to the dev guide`
The commit description should have more detailed explanation covering also the purpose
of the work being done. Formatting guidelines include:
- Must be separated from the title by a blank line.
- Must be wrapped to 72 characters, unless it is a sample output.
- Markdown syntax/output code blocks (3 ticks "```" line before and after).
- Write your commit message in the imperative: "Fix bug" and not "Fixed
bug" or "Fixes bug." This convention matches up with commit messages
generated by commands like git merge and git revert
- Bullet points are okay, too.
- Typically a hyphen or asterisk is used for the bullet, followed by a
single space. Use a hanging indent.
Example good commit message:
.. code-block:: console
pim6d: support embedded-rp
Implement embedded RP support and configuration commands.
Embedded RP is disabled by default and can be globally enabled with the
command `embedded-rp` in the PIMv6 configuration node.
It supports the following options:
- Embedded RP maximum limit
- Embedded RP group filtering
When opening a PR, please follow the same commit message guidelines above. Also
make sure:
- If the PR has a single commit, just copy the commit message as-is to the PR,
which is the default behavior for a single commit PR on github.
- If the PR has more than one commit, add a summary title for the whole PR
along with a summary description encompassing all commits.
- Make sure that the description you add to the PR is already captured in commits messages.
In other words don't leave the commit messages empty. The PR description should just restate
or summaries what the the commit messages already have.
Why was my pull request closed?
-------------------------------