Contribution Guide

Commits

Git commit messages in this repository use the Conventional Commits specification.

The commit message should be structured as follows:

<type>[optional scope]: <summary description>

[optional body]

[optional footer(s)]

While the specification allows for an optional commit message body, we strongly recommend, if not require, its inclusion. The body should specify why the change is made, not how it was made, as the how can be inferred by reading the commit diff.

Commit Header Examples

feat: new feature
fix(scope): bug in scope
feat!: breaking change / feat(scope)!: rework API
chore(deps): update dependencies

Commit Types

Commits must be prefixed with a type, which consists of a noun, feat, fix, etc., followed by a colon and a space. In this repository, the type must be lowercase, and must be one of the following:

build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
ci: Changes to CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
chore: Changes which do not change source code or tests e.g. changes to the build process, auxiliary tools, libraries
docs: Documentation only changes
feat: A new feature
fix: A bug fix
perf: A code change that improves performance
refactor: A code change that neither fixes a bug nor adds a feature
revert: Revert changes
style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
test: Adding missing tests or correcting existing tests

Commit Scopes

An optional scope may be provided after a type. A scope must consist of a noun describing a section of the codebase surrounded by parenthesis, e.g., fix(parser).

images: Changes to the standard images provided by the repository.
linux: Changes to the reference kernels.
distro-apt: Changes to package feed construction, contents, or usage.
packages: Changes to packages, or additions of new packages in the form of new recipes. Additions of packages to a feed or image will be covered by the other scopes.
bsp: Changes to one or more BSPs, in the form of changes to the machine configuration or associated files, such as WKS files which are machine-specific.
distro: Changes to the distro configuration, which includes debian version and distro-specific changes elsewhere.

Commit Summary

The summary contains a succinct description of the change:

use the imperative, present tense: "change" not "changed" nor "changes"
don't capitalize the first letter
no dot (.) at the end

Limit the full summary line to 50 characters, if possible.

Commit Body

Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior. The focus should be on describing why a change was made, not the details of what was changed and how. Limit body lines to 72 characters.

Commit Footer(s)

Footers are optional, but can provide additional metadata for a commit; be used to alert readers and tools to significant changes such as breaking changes; or can link commits to issues or pull requests. Footers are written using the format:

<token>: <value>

The Conventional Commits specification introduces the BREAKING CHANGE footer token that is used to indicate that the commit introduces a non-backwards compatible change. The ! indicator in the commit type also indicates a breaking change, so the footer is unnecessary when used.

Reminders

The blank line between the summary and commit body is required.
More details at Conventional Commits.
Commit messages for a revert should follow the recommendation in the Specification.

kergoth/CONTRIBUTING.md