On 10-11-12 09:46, David Smith wrote: >> Why did you update libtool-dont-rearange-as-needed patch without >> any functional change? > > While inspecting / testing if it was still needed, I may have > inadvertently updated the date on the file. No changes in the file, > I have restored the original file in preparation for my next > attempt. The following is noise: ---- liferea-1.8.3.orig/ltmain.sh -+++ liferea-1.8.3/ltmain.sh +--- a/ltmain.sh ++++ b/ltmain.sh >> You did not allow the maintainer of this package much time to >> review most of your patches, but than again, this package has some >> history of new releases via NMU. Did you check the freeze policy >> [1]? > > The maintainer Luis Rodrigo Gallardo Cruz <rodrigo@debian.org>. Is > on the "low-threshold" list. So I figured I could save him some > work by doing the NMU myself. Although, this is my first NMU. I > thought it would be a good opportunity to learn the NMU process. Good. If you care for liferea, you could also propose to co-maintain it. > Some of the other important bugs are very old (years) and I wasn't > able to reproduce them. Please tag them as unreproducible [1] > Some of them, I'm waiting for people to get back to me on if they > still impact the latest version of liferea. I think you have tagged them with moreinfo, right? > The rest probably should be forwarded to upstream as I don't think > it's an easy fix if they're still valid bugs. So you have added this information as well. Don't hesitate to forward them (and tag them as such of course), but it would be nice to reproduce if possible. >> Are really all these bugs of the proper severity? I.e. bug 692007 >> does not seem to qualify in my view (although *you* marked it as >> important later, but when you submitted you did not think it >> important). You can try, but I am unsure if this would qualify for >> an unblock (maybe in addition to the rest). > > In my opinion, they are. Originally I was using this software with > only a few feeds. When I added more feeds, I realized this was a > more serious bug as it then started spamming the user's desktop with > notifications on feeds that have already been read. Further, they > keep triggering every refresh so it's pretty much endless. I > suppose the user could just turn the notifications off for the app, > but I thought it better to just fix it. Liferea is a news reader > and people use it to get live updates to newstreams via RSS so I > personally wouldn't use the package without the patch so I thought > it should be "important". I understand. It is just that the release-team might disagree. But off-course you can try. Next time, (or even now as a comment) add this kind of justification to the command where you raise the severity. >> Some of your patches change unnecessary things such as whitespace, >> capitalization or copyright dates. If I was release manager I >> would prefer you leave the changes to the functional parts. You can >> add the copyright notice with the date to the header of the patch >> instead, if you want. I think added comments to added code are >> fine. > > I pretty much took those slightly bloated (with comments/whitespace) > patches directly from upstream. I wasn't sure if it was ok to simply > not include parts of upstream patches. I could trim them down a bit > and move the copyright to the patch header if that's preferred or > makes it easier to see what has changed. The release team made it clear that changes should be clean, i.e. your changes of getting an unblock are higher if you remove everything that is not necessary. >> Why add a patch that you don't use, probably a mistake. >> (google_source-*) > > Yes, mistake. I started a patch with that name, but then I imported > the upstream patch file and just used that instead. So remove it. :) > 3. I sent the bug report to the package itself using nmudif instead > of to sponsorship-requests (using the mentors template) which I will > fix for my next attempt. But don't forget to update the bug report in the package with newer debdiff's nevertheless. I think sending it to the package is good. Sending it to mentors is also good, as you can not upload yourself. Question to mentors: should we use "affects" in this case, or does that not work? Paul [1] http://www.debian.org/Bugs/server-control#tag
Attachment:
signature.asc
Description: OpenPGP digital signature