On Sun, 30 Apr 2006 12:18:14 -0500, Jason L Tibbitts III wrote: > >>>>> "MS" == Michael Schwendt <bugs.michael@xxxxxxx> writes: > > MS> You can look _into_ rpms just fine and skim over any included > MS> ChangeLog, NEWS, README files. > > Please tell us how you would do so. Assume the usual case, that the > package is in a remote yum repo. A fearful user downloads new packages and performs a test upgrade on a test machine. A fearful user knows that any shiny new version upgrade may lead to severe regression, brown paperbag bugs, and other defects, regardless of how upstream advertises the NEWS in their doc files. If you mix upstream ChangeLog details and packaging %changelog details, you create a blurred picture of who did what. Further, some upstream developers are very verbose in their ChangeLogs, so as soon as you started trying to sum up the changes in a new version, you would either fail or end up copying the entire ChangeLog into your spec file. In general, let users assume that a version upgrade is bigger'n'better unless it failed during your packaging QA. The majority of end-users are not interested in implementation details in developer ChangeLogs unless they are confronted with run-time misbehaviour. And even then, many of them don't read ChangeLogs to find out which CVS commit may have been the culprit. > Remember that we have no announcement mechanism for Extras packages, > so we have no way to communicate possible incompatible updates to > users. Obviously the idea is to not introduce any incompatible > changes within a single Fedora release, but eventually it's going to > happen and surely a sentence in the %changelog can do nothing but > help. This belongs into the "spec %changelog should [...] cover important changes in the packaging" as an incompatible version upgrade means that you need to put a warning into your %changelog because _you created_ an _incompatible package_. -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
