Uploaded (was: RFS: ripit (updated package))

[Adeodato Simó <dato@net.com.org.es>]

+ Elimar Riesebieter (Fri, 17 Apr 2009 19:04:15 +0200):

> Dear mentors,

Hello, Elimar. (Elimar is one of our capable ALSA maintainers, by the
way.)

> I am looking for a sponsor for the new version 3.7.0~beta20090329-1
> of my package "ripit".

> It builds these binary packages:
> ripit      - Textbased audio cd ripper

> The package appears to be lintian clean.

> The upload would fix these bugs: 490082, 501925, 517561, 518720

I’ve uploaded your package. I have the following comments, please
consider improving your package based on this feedback on the next
upload(s):

  * Please only close bugs with a “New upstream version” message if
    they’re actually a wishlist bug asking for the new version to be
    packaged. In case they are actual bugs, please do something like:

      * New upstream release:
        + does not prepend “fast” to the “insane” preset. (Closes: #501925)
        + copes with lame sending --genre-list output to stderr.
          (Closes: #490082)
        + fixes genre parsin or whatever. (Closes: #517561)

    I hope you’ll agree that’s more useful for the person reading the
    changelog, and it only takes a bit more effort. No need to
    retroactively edit the changelog, though.

  * Any reason not to make build-stamp in debian/rules depend directly
    on $(QUILT_STAMPFN), instead of an intermediate configure-stamp
    which, in addition, does not get touch'ed?

  * rm'ing .pc in clean is unnecessary: the “unpatch” target does it.
    Additionally, .pc is a directory, so at the moment your clean target
    is not failing because “unpatch” gets to run first and deletes .pc.

  * You could add a space after “Homepage:”.

Thanks for your contribution to Debian!

P.S.: I’m well aware most sponsors would have done another round of
packages and waited for the above issues to be fixed. I myself prefer to
upload unless there are serious or unacceptable issues. This way, is my
belief, sponsorees are taught to be more careful, rather than
unconsciously think “Ok, I have a preliminary version, sponsor will
catch mistakes”. Which is a disaster once they gain upload rights. Also,
if there are serious or unacceptable mistakes, I usually try the
“You introduce a serious issue in the clean target of debian/rules,
please see if you can find it” route first.

Cheers,

-- 
- Are you sure we're good?
- Always.
        -- Rory and Lorelai