Difference between revisions of "VPP/CommitMessages"

Revision as of 19:35, 12 August 2020

WIP: comments => ayourtch@gmail.com

If you browse the git log, you notice that all the commit messages have the common structure:

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

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.

Comments => ayourtch@gmail.com