A ChangeLog must be included with every patch submitted.
- Don't add the changelog changes to the patch. Write it as part of the email.
- Separate entries that are meant for different changelog files.
- Add information about related bugs (PRs), one per line, if any.
- Asterisks are only used for the first line of each file's changes.
- TABs at the start of every line. Place the name of the affected entity (function, variable or macro) in parenthesis at the start of each line, colon, space, then say what not why.
- The DATE is the date of the commit, so it should be updated before the commit.
Roughly, the format should be:
YEAR-MONTH-DAY Name <EMAIL> PR bugzilla_component/NUMBER PR bugzilla_component/NUMBER2 * file (function): Change. (another function): Change. Change2. * file2: New file. * file3: Delete.
An example of changelog is:
2007-01-27 Manuel Lopez-Ibanez <manu@gcc.gnu.org> PR c++/24924 * c-opts.c (c_common_post_options): Handle C++ post-processing here. Set also -pedantic-errors by default for the preprocessor unless -fpermissive is given. cp/ * decl.c (cxx_init_decl_processing): Move command-line options processing to c-opts.c. testsuite/ * g++.dg/cpp/pedantic-errors.C: New. * g++.dg/cpp/permissive.C: New.
You can find more examples by browsing the archive of gcc-patches mailing list.
For the full and minute details, see the "Change Logs" chapter of the GNU Coding Standards. 1
Tools like vc-chlog can help create stub ChangeLog entries, which are already split up for the individual ChangeLog files and list files and functions that were changed.
It's fair to say that in GCC's ChangeLogs, the part about "Conditional Changes" is more honoured in the breach than the observance... (1)