6.3.1. Writing useful changelog entries

The changelog entry for a package revision documents changes in that revision, and only them. Concentrate on describing significant and user-visible changes that were made since the last version.

Focus on what was changed — who, how and when are usually less important. Having said that, remember to politely attribute people who have provided notable help in making the package (e.g., those who have sent in patches).

There’s no need to elaborate the trivial and obvious changes. You can also aggregate several changes in one entry. On the other hand, don’t be overly terse if you have undertaken a major change. Be especially clear if there are changes that affect the behaviour of the program. For further explanations, use the README.Debian file.

Use common English so that the majority of readers can comprehend it. Avoid abbreviations, tech-speak and jargon when explaining changes that close bugs, especially for bugs filed by users that did not strike you as particularly technically savvy. Be polite, don’t swear.

It is sometimes desirable to prefix changelog entries with the names of the files that were changed. However, there’s no need to explicitly list each and every last one of the changed files, especially if the change was small or repetitive. You may use wildcards.

When referring to bugs, don’t assume anything. Say what the problem was, how it was fixed, and append the closes: #nnnnn string. See When bugs are closed by new uploads for more information.