Changelogs
Every time you make changes, that is, whenever you increment the E-V-R of a package, add a changelog entry. This is important not only to have an idea about the history of a package, but also to enable users, fellow packages, and QA people to easily spot the changes that you make.
If a particular change is related to a Bugzilla bug, include the bug ID in the changelog entry for easy reference, e.g.
* Wed Jun 14 2003 Joe Packager <joe at gmail.com> - 1.0-2 - Added README file (#42).
You must use one of the following formats:
* Fri Jun 23 2006 Jesse Keating <jkeating@redhat.com> - 0.6-4 - And fix the link syntax.
* Fri Jun 23 2006 Jesse Keating <jkeating@redhat.com> 0.6-4 - And fix the link syntax.
* Fri Jun 23 2006 Jesse Keating <jkeating@redhat.com> - 0.6-4 - And fix the link syntax.
When you take over maintenance of a package, you should follow the style that the package already uses for consistency. Changelog entries should provide a brief summary of the changes done to the package between releases, including noting updating to a new version, adding a patch, fixing other spec sections, note bugs fixed, and CVE's if any. They must never simply contain an entire copy of the source CHANGELOG entries.
The intent is to give the user a hint as to what changed in a package update without overwhelming them with the technical details. Links to upstream changelogs can be entered for those who want additional information.