-revision, and only them. Concentrate on describing changes you did since
-the last version that are worth mentioning.
- <p>
-Focus on <em>what</em> 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).
- <p>
-There's no need to elaborate the trivial and obvious changes. You can also
-aggregate several such changes in one entry. However, 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 -- and for further
-explanations, use the <file>README.Debian</file> file.
- <p>
-Use common English language, one which the majority of viewers can
-understand. Avoid abbreviations, "tech-speak" and jargon when explaining
-changes that close bugs, especially if the said bugs were filed by users
-that did not strike you as particularly techically savvy. Also, be polite,
-don't swear.
- <p>
-It is customary to prefix changelog entries with the names of the files that
-were changed. There's no need to explicitely list each and every last one of
-the changed files, especially if the change was small or repetitive -- use
-wildcard characters wisely.
- <p>
-When referring to bugs, don't assume anything -- say what the problem was,
-how it was fixed, and append the "closes: #nnnnn" string.
-See <ref id="upload-bugfix"> for more information.
-
- <sect1 id="bpp-changelog-dont">
- <heading>Common misconceptions about changelog entries</heading>
- <p>
-The changelog entries should <strong>not</strong> document generic packaging
-issues ("Hey, if you're looking for foo.conf, it's in /etc/blah/."), since
-administrators and users are supposed to be at least remotely acquainted
-with how such things are generally arranged on Debian systems. Do, however,
-mention if you change the location of a configuration file.
- <p>
+revision, and only them. Concentrate on describing significant and
+user-visible changes that were made since the last version.
+ <p>
+Focus on <em>what</em> 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).
+ <p>
+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 <file>README.Debian</file> file.
+ <p>
+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.
+ <p>
+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.
+ <p>
+When referring to bugs, don't assume anything. Say what the problem
+was, how it was fixed, and append the "closes: #nnnnn" string. See
+<ref id="upload-bugfix"> for more information.
+
+
+ <sect1 id="bpp-changelog-misconceptions">
+ <heading>Common misconceptions about changelog entries</heading>
+ <p>
+The changelog entries should <strong>not</strong> document generic
+packaging issues ("Hey, if you're looking for foo.conf, it's in
+/etc/blah/."), since administrators and users are supposed to be at
+least remotely acquainted with how such things are generally arranged
+on Debian systems. Do, however, mention if you change the location of
+a configuration file.
+ <p>