Difference between revisions of "VPP/CommitMessages"

From fd.io
< VPP
Jump to: navigation, search
(Created page with "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...")
 
(Blanked the page)
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
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.
 
 
 
Comments => ayourtch@gmail.com
 

Latest revision as of 19:44, 12 August 2020