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:
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.
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.
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.
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 => email@example.com