|
|
| Line 1: |
Line 1: |
| − | WIP: comments => ayourtch@gmail.com
| |
| | | | |
| − | If you browse the git log, you notice that all the commit messages have the common structure:
| |
| − |
| |
| − | <pre>
| |
| − | component-or-space-separated-component-list: one-line description of what this commit is about
| |
| − |
| |
| − | Then there are potentially
| |
| − | multiple
| |
| − | lines
| |
| − | describing the commit.
| |
| − |
| |
| − | Type: fix|feature|improvement|refactor
| |
| − |
| |
| − | Signed-by: Author
| |
| − | Change-Id: change-id
| |
| − | </pre>
| |
| − |
| |
| − | This format is enforced by the "checkstyle" Jenkins job that runs before the make verify jobs, and gives a shortcut -1 JJB vote
| |
| − | if the commit message format is incorrect.
| |
| − |
| |
| − | This formal structure allows to perform various operations automatically:
| |
| − |
| |
| − | 1) The component-or-space-separated-component-list comes from MAINTAINERS file. This gives an achor towards whose area
| |
| − | of responsibility this commit falls into.
| |
| − |
| |
| − | 2) The "Type" allows to make a quick automatic assessment of what the commit is about:
| |
| − |
| |
| − |
| |
| − | Type: feature
| |
| − |
| |
| − | The commits of this type are deemed big/important enough to showcase in the Release Note for the upcoming release,
| |
| − | and the capitalized "one-line description of what this commit is about" is used to have a one-line in
| |
| − | the Release Note, mentioning this commit, along with the commit ID.
| |
| − |
| |
| − | Type: improvement
| |
| − |
| |
| − | This is a feature's little sibling - a nice to have, and a nice contribution to the world, but deemed
| |
| − | to be too niche or specialized or minor to make it to the Release Notes automatically. (Of course,
| |
| − | the committer may chose to include a one-liner still, but they will have to do so manually during the period
| |
| − | of the Release Note review following the RC1/RC2 milestones.
| |
| − |
| |
| − | Type: fix
| |
| − |
| |
| − | This is a bugfix. These will be typically be small, however, it is not unheard of to have a larger commit here.
| |
| − | This commit type will be the primary candidate for consideration to include into the LTS/stable branches
| |
| − | by means of automatic cherry-pick.
| |
| − |
| |
| − | Type: refactor
| |
| − |
| |
| − | A typically large-ish rewrite, that changes the code internally and typically does not alter the user-visible behavior,
| |
| − | is mostly there to help with the ongoing maintenance of the code.
| |
| − |
| |
| − | Note that although the "fix" is the primary target for the cherry-pick, to ensure everyone's sanity, the feature, improvement, and refactor commits may also be cherry-picked into the LTS branches after a certain time period has elapsed and their properties are
| |
| − | understood bug-wise.
| |
| − |
| |
| − | Type: style
| |
| − |
| |
| − | These commits fix the typos and formatting in the code, and should not result in any change of the behavior.
| |
| − |
| |
| − | Type: docs
| |
| − |
| |
| − | Documentation edits.
| |
| − |
| |
| − | Type: test
| |
| − |
| |
| − | Operations on the test infra/tests, that do not involve the VPP code itself.
| |
| − |
| |
| − | Type: make
| |
| − |
| |
| − | Edits to the build infrastructure. The effects may vary.
| |
| − |
| |
| − |
| |
| − | Comments => ayourtch@gmail.com
| |
