The Commit and Patch Message Guidelines -- Approved

[Mark Hatle <mark.hatle@windriver.com>]

On behalf of the Technical Steering Committee,

I am happy to announce the approval of the final version of the Commit and Patch
Message Guidelines.

Thank you to everyone who contributed to document.  If anyone has any questions,
comments or concerns feel free to let me or any of the other TSC members know.

See http://wiki.openembedded.org/index.php/Commit_Patch_Message_Guidelines

Some of you may be wondering what this is, below is a snippet from the guidelines.

This set of guidelines is intended to help both the developer and reviewers of
changes determine reasonable patch headers and change commit messages. Often
when working with the code, you forget that not everyone is as familiar with the
problem and/or fix as you are. Often the next person in the code doesn't
understand what or why something is done so they quickly look at patch header
and commit messages. Unless these messages are clear it will be difficult to
understand the relevance of a given change and how future changes may impact
previous decisions.

This policy refers both to patches that are being applied by recipes as well as
commit messages that are part of the source control system, usually git. A patch
file needs a header in order to describe the specific changes that are made
within that patch, while a commit message describes one or more changes to the
overall project or system. Both the patch headers and commit messages require
the same attention and basic details, however the purposes of the messages are
slightly different. A commit message documents all of the changes made as part
of a commit, while a patch header documents items specific to a single patch. In
many cases the patch header can also be used as the commit message.

This policy does not cover the testing of the changes, or the technical criteria
for accepting a patch.

By following these guidelines we will have a better record of the problems and
solutions made over the course of development. It will also help establish a
clear provenance of all of the code and changes.

Approved by the Technical Steering Committee 2011/06/09.