Spec URL: http://avi.alkalay.net/software/id3mtag/id3mtag.spec SRPM URL: http://avi.alkalay.net/software/id3mtag/id3mtag-0.78-3.fc12.src.rpm Other: http://avi.alkalay.net/software/id3mtag/ Description: ID3 mass tagger is a tool for manipulating id3 and id3v2 tags in multiple files. It can generate tag fields from the filename and other variables, and/or rename files, using an intuitive syntax.
*** Bug 477958 has been marked as a duplicate of this bug. ***
Sorry for the loooooong delay. Everithing requested to be fixed on #477958 was fixed and I believe this is now ready. Thanks in advance for reviewing.
Also check some notes about what this tool can do for you: http://avi.alkalay.net/2009/06/mp3-mass-tagging-and-organization.html
I suggest you to persuade upstream to rename %{_bindir}/id3 to %{_bindir}/id3mtag as well. It will conflict with some other packages that haven't in fedora temporarily. See http://fedoraproject.org/wiki/Packaging:Conflicts
> Patch: string-include.patch > %patch -p1 Do add explicit numbers to patch files to avoid confusion when adding further patches. Start with 0 or 1: Patch0: string-include.patch %patch0 -p1 Further, it would be a good habit to move the patch files into the package namespace: Patch0: id3mtag-string-include.patch And even better, mention also the %version, so the "age" and target of patches become clear: Patch0: id3mtag-0.78-string-include.patch > #Packager: squell <squell> > #BuildRoot: %{_tmppath}/%{name} At least the Packager tag ought to be dropped, since it isn't used within the Fedora Package Collection and -- if commented out -- it only adds ambiguity. About BuildRoot, either drop it completely or follow the packaging guidelines.
Any response to the above commentary?
Yes, my response would be: I HAVE NEVER MANAGE TO GET A PACKAGE FULLY APROVED ON FEDORA BECAUSE OF THIS VERY METICULOUS, NEVER ENDING, OBSESSIVE USELESS-DETAIL-ORIENTED COMMENTS. ITS ALSO USELESS TO FIX TO FULFILL THE COMMENTS BECAUSE A NEW REVIEWER APPEARS WITH NEW MORE OBSESSIVE AND METICULOUS COMMENTS IN A NEVER ENDING LOOP. I'll fix this when I have time. Jason, meanwhile you can use the RPMs available in link above. (I thing there are new versions there). This useless meticulous process makes Fedora packages great but are also killing the distro because of delays in approvals. It should be relaxed a little bit, in my opinion. Sorry for being so direct. (In reply to comment #6) > Any response to the above commentary?
I was actually looking at these old tickets with an eye towards trying to work on getting them approved, but I think I'll just skip this one. Somehow our package count continues to grow at a significant rate, so people are getting packages through the process without too much difficulty. Personally I've no intention at all of relaxing our guidelines or accepting anything less than quality packages, because poor packaging harms the distro more in the long run than upsetting someone because they don't feel they want to put the work in. Ah, well, we could have a couple of back-n-forths beating this package into shape, and it would be done.
All done. http://avi.alkalay.net/software/id3mtag/id3mtag-0.78-4.fc13.src.rpm Whats next ? Thanks in advance (In reply to comment #5) > > Patch: string.....
> Sorry for being so direct. It doesn't change a thing, though. It's not the first time you've failed to respond during review. Bug 477958 is just the old ticket for the previous review of this package. It should have been reopened instead of restarting here. Especially, since the non-responsiveness has led to dropping the NEEDSPONSOR blocker bug dependency, which hasn't been added to this new ticket. You are free to disagree, but what I've commented on is a real packaging mistake that reduces the quality of your spec file. If you don't show interest in hints about packaging problems which affect your own package, it will be difficult to find somebody to sponsor you. If you don't find the time to respond during review, why would you respond to general bug reports and other requests, which take more time than a trivial packaging fix?
I'm sorry, but some reviewer closed that bug and asked to open a new report when I'll be ready to continue: https://bugzilla.redhat.com/show_bug.cgi?id=477958#c7 See!? I just opened a new one because of this comment. Michael, you are not the first commenter. I'm very meticulous with my RPMs but the process just goes beyond that with even more meticulous things, and one commenter seems to only look at one point and not the whole package, so the packager has to make several releases, to satisfy each reviewer.
I love the beauty of Fedora packages but I'd like to do all edits in one shot because of time concerns, not 1 char per reviewer. If you look at those 2 bug reports with the whole timeline of comments and edits, I think there were 4 or 5 different reviewers, each looking at different problems of the package. The report bounced too much and at the end I lost tracking. This is not my first submitted package where I lost tracking.
So, instead of posting a short comment to acknowledge things a reviewer seems to have found, you either stay away for a long time or you prefer to argue. Some things to consider: * You don't need to publish a new src.rpm/spec for every single issue reported by a reviewer. You are free to collect the found issues, depending on whether the src.rpm builds at all, of course. * However, you are expected to communicate with the reviewers and either confirm the found problems or explain why you do something differently (and possibly in violation of the guidelines). Many reviewers expect you to offer something you consider "final" before they would allocate the time to work with you on your package or your sponsorship. * In the same way, reviewers are not expected to be perfect at finding _all_ issues with a single look at the package. The more issues there are, the more time it takes to spot [or understand] non-obvious things which don't break the build but which are against the guidelines nevertheless. It's normal that reviewers find some issues, which are not covered by the packaging guidelines, but which are bad or fragile. The guidelines aren't complete and never will be. [...] Further comments to your replies: > I just opened a new one because of this comment. As I understand it, Mamoru suggested closing this old ticket because it's the cleanest way for _somebody_ to take over a stalled package review ticket (other than reassigning it and keeping old cruft). The old one has been without a sign of life from you for over four months. And once closed, somebody else with interest in packaging the same software would simply open a new review ticket anyway and not search in the pile of DEADREVIEW tickets. > If you look at those 2 bug reports with the whole timeline of comments > and edits, I think there were 4 or 5 different reviewers, A single one only. He even promised a complete review, albeit pointed out that he could not be your sponsor. No response from you at all. No response -> no review -> no progress. Then, in this new ticket, you didn't follow the documentation for new packagers, https://fedoraproject.org/wiki/Join_the_package_collection_maintainers https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group so you didn't even appear on the NEEDSPONSOR list, and again you didn't respond. > The report bounced too much and at the end I lost tracking. I fail to understand that. Two comments on the package. No response.
OK, I guess I talk too much. What are the next steps to get this approved ? Thank in advance
http://fedoraproject.org/wiki/Join_the_package_collection_maintainers http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group and http://fedoraproject.org/wiki/Package_Review_Process