On Sun, 2006-04-30 at 12:00 +0200, Joost Soeterbroek wrote: > %changelog > * Thu Apr 27 2006 Joost Soeterbroek <fedora@xxxxxxxxxxxxxxx> - 2.0.5-1 > - upstream version 2.0.5 > - removed patch2 - ownership of /heartbeat/crm/cib.xml is no longer > set in cts/CM_LinuxHAv2.py.in > + Version 2.0.5 - significant bug fixes and a few feature deficits fixed > + various portability fixes > + enable GUI to run with pygtk 2.4 > + significant GUI improvements and speedups > Many ChangeLogs are logs of what has changed in every cvs checkin. That is of little use in a spec file's ChangeLog. What you have here is a summary of changes which is more what I think of in a traditional NEWS file. This seems within the realm of reason. However, even here somethings are extraneous: "various portability fixes" -- If it's architecture portability we care, if it's OS portability it's better off in the ChangeLog file. "enable GUI to run with pygtk 2.4" -- We don't really care what pygtk version upstream has ported to. We care what versions of Core the heartbeat package runs on. The package maintainer could have added patches to make it work with a different pygtk version. Core could have a version of pygtk on which heartbeat worked before these changes. Summary: duplicating information into the spec ChangeLog that fit better in a different file makes little sense. This argues that a packager can list the major features that upstream has implemented (and fixes to bugs that are in bugzilla.redhat.com) but they should consider what they are adding to the spec file. Even summaries of features as seen in the NEWS file can contain information not relevant to the consumers of pre-packaged binaries. Sidenote: Organizationally, I'd put the upstream changes under the note about upstream version:: - upstream version 2.0.5 + significant bug fixes and a few feature deficits fixed + various portability fixes - removed patch2 - ownership of /heartbeat/crm/cib.xml is no longer set in cts/CM_LinuxHAv2.py.in -Toshio
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
