On Sat, 29 Dec 2012 20:20:25 +0100, Alec Leamas wrote: > On 2012-12-29 19:45, Michael Schwendt wrote: > > On Sat, 29 Dec 2012 18:23:35 +0000, Jamie Nguyen wrote: > > > >> I've seen on a few occasions reviewers mention that they can't tell what > >> has changed in the spec since the previous version, as the new packager > >> has overwritten the previous spec. > > If the packager does that, it makes the rpmdev-diff command less useful, > > The src.rpm file name should be different for each new update to the spec > > file. > Mixed feelings... Although the purpose and benefits of this is obvious: > - If we cannot applyt the new changleog GL with changes without > version bump in a review process, when should they then be applicable?! Offering a src.rpm for review is very similar to releasing it in koji. Once built in koji, the NEVR is occupied and blocked, so future builds must bump R, at least. During review, you offer a release of a src.rpm. If it needs to be changed in any way, it becomes necessary to release an update to the src.rpm. For updates, especially those that don't fail to build, one typically bumps R at least, or else you couldn't simply update to the builds (because you would need to _reinstall_/replace an already installed package. If the packager modifies a src.rpm, the guidelines ask that a changelog entry is to be added. http://fedoraproject.org/wiki/Packaging:Guidelines#Changelogs The wording isn't fully safe. It's not a strict "you must add a changelog entry any time you change the spec file" or anything like that. Personally, I consider it okay if a package submitter doesn't bump R as long as %changelog entries are added. It's easy enough to append a number to downloaded srpms, so they could be diffed conveniently. It's also pretty much okay to flush/delete the changelog entries for the approved src.rpm prior to git import, and to reset R to 1. It depends on what has been changed during review and what could be important to keep in the changelog. > - But without version bump, the srpm file will get the same name. And > both srpm and spec have more or less fixed names for a given package and > e-v-r. - the only really consistent scheme is using a directory for each > change. Certainly doable but given all the obstacles specially new > submitters meet, this might be to much? I don't think it's too much of a requirement for new packagers to upload new src.rpms and announce the new link in a comment. The spec download may stay the same for quick/convenient access (and because there is not version in its file name, of course). > It might perhaps be helpful to add a note to the review process that a > change in the spec+srpm should be treated as a 'change' in the changelog > GL sense?! I'm a bit surprised I cannot find anything like that, > thought we all did so :) It depends. Not everything needs to be documented painstakingly. It's not worth the effort. During review it's merely a matter of practising changelog maintenance. Also, I dunno how many package submitters don't maintain their changelogs during review or simply are too lazy to do that, but would do it for future updates in the Fedora package collection. If we try to force package submitters to add changelog entries during review, that will likely lead to many irrelevant entries, such as "fixed summary", or lack of details, such as "fixed license", with the reviewer having to comment on that, too. That could get tiresome. Packagers only need to be aware of the %changelog and apply common sense. ;) -- Fedora release 18 (Spherical Cow) - Linux 3.6.11-3.fc18.x86_64 loadavg: 0.30 0.23 0.23 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
