[Bug 193224] Review Request: streamer

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: streamer


https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193224





------- Additional Comments From paul at city-fan.org  2006-05-30 09:11 EST -------
(In reply to comment #9)
>      I didnt get what u mean by 
> >Thanks. What appears to have happened now is that upstream (you) have released a
> >new tarball at version 1.1 that contains the GPL file, which was not the case
> >with the version 1.1 tarball I last looked at. *Please* don't release new
> >tarballs with the same version numbers as previous releases - that's a really
> >bad habit to get into.

OK, I'll give examples. In your original bugzilla submission for this package
you posted a URL for streamer-1.1-2.fc5.src.rpm. This SRPM contains a tarball
streamer-1.1.tar.bz2. In Comment #7 you posted a URL for
streamer-1.1-3.fc5.src.rpm, another SRPM, which also contains a tarball
streamer-1.1.tar.bz2. However, this was different from the previous tarball of
the same name because it contained an additional file, "GPL". In Comment #9 you
reposted the same URL as in Comment #7, but now the SRPM at that URL contains
yet another version of streamer-1.1.tar.bz2 that is different from the previous
two releases. So if I refer in my review to a problem with the streamer version
1.1 release, what am I actually referring to? There are to my knowledge at least
three different things that could be described as streamer version 1.1. This is
terribly confusing. 

To avoid this confusion, follow these rules of thumb:
1. If you change the contents of a tarball, no matter how minor the change, the
version number of that tarball (and hence the package containing it as well)
should be increased.
2. If you change any other aspect of the package, such as a spec file, adding or
changing a patch etc., the release number of the package should be increased.
This ensures that there is never a case where there are two different packages
with the same name but different contents.

>   Also i solved rpmbuild "file included twice" warnings and some other warnings.

Yes, that's good.

> Other signedness warnings are ok as they are compiler specific. Same warnings
> are not coming on FC4 and RHEL systems.

You'll need to build on FC5 or later to see some of these warnings. The ones I
was most concerned about are still there:

  CC      console/capture.o
console/capture.c: In function 'ng_grabber_setformat':
console/capture.c:183: warning: pointer targets in passing argument 1 of
'ng_ratio_fixup' differ in signedness
console/capture.c:183: warning: pointer targets in passing argument 2 of
'ng_ratio_fixup' differ in signedness
console/capture.c: In function 'movie_writer_stop':
console/capture.c:528: warning: integer constant is too large for 'long' type
console/capture.c:533: warning: integer constant is too large for 'long' type
console/capture.c: In function 'movie_print_timestamps':
console/capture.c:588: warning: integer constant is too large for 'long' type
console/capture.c:588: warning: integer constant is too large for 'long' type
console/capture.c: In function 'movie_grab_put_video':
console/capture.c:624: warning: integer constant is too large for 'long' type

>    Do i need to update to new release number. if yes why?? i only solved
> warnings not added any feature.

The package has changed. It's a new release, different from the previous one.
The release number should be increased and there should be a changelog entry
describing the changes (note: the changelog in the RPM spec describes the
changes to the packaging rather than the changes to the application itself -
changes to the application are normally described in a changelog file in the
application's tarball).

-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.