Everything changes, so do our packages. But change needs to be explained in order to become relevant. Regarding packaging, this involves the art of writing good changelog entries. Here is an example from an otherwise very capable packager:
- Spec files updates:
- Changes in License.
- Updates in Group:, Summary: and %description entries.
- Updates in %build section for lib64 compilation.
- Minor other updates.
More often, a reviewer stumbles upon those classics:
- Fixed build
- Fixed dependencies
- Changed license to $FOO
These lines surely took some time to write but they explain only what was changed, not why. The ‘what’ is easily visible from the diff of the old and new package version (kindly provided by the Open Build Service), but it’s the ‘why’ that matters. Your benevolent Factory review team kindly overlooks such insignificant matters most of the time, but you may leave your users baffled. Changelogs usually serve a purpose, for the package reviewer it’s ‘Why should I take the time to look at this at all and why does it belong into Factory?’. For the user it’s simply, ‘Dang, yet another update, why’s that for?’. You better provide some good answers for those questions or your carefully crafted fix may remain misjudged. As a reference you may use guides that others have written. They’re mostly about VCS commit messages, but it’s the same thing:
- http://who-t.blogspot.com/2009/12/on-commit-messages.html
- http://lbrandy.com/blog/2009/03/writing-better-commit-messages
Happy changelog writing!
Sascha Peilicke 