package reviews: new Release for every update

[Michael Schwendt]

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