Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=529496 Michael Schwendt <mschwendt@xxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mschwendt@xxxxxxxxx --- Comment #15 from Michael Schwendt <mschwendt@xxxxxxxxx> 2010-01-12 06:04:54 EST --- > There's a difference between a *requirement* and a *recommendation*. One reason why some of Fedora's guidelines have been upgraded from a SHOULD to a MUST or vice versa. All SHOULD items could be dropped from the Wiki if there were no interest in making them recommendations. Several things I suggest in my reviews are a SHOULD, albeit with a rationale (such as mentioning what is considered common practise or a good habit). Fedora's guidelines will never be complete and will never cover everything -- or else they would reach the size of a book. > It is perfectly OK for me not to follow a *recommendation*, and you > should not punish me for having a different opinion. Nah, I don't punish anyone "for having a different opinion". Just as you like to retain your freedom to do many things the way you like to, I'm not being forced to give blanket-approval to arbitrary people. Afterall, there even are recommendations about what ought to happen before someone gets sponsored: https://fedoraproject.org/wiki/PackageMaintainers/HowToGetSponsored#Reviewing_Packages I don't do many reviews anymore these days (perhaps one a week), but typically I'm mostly interested in finding out whether a person is open-minded and easy to deal with, and whether a person is willing to absorb the Packaging documentation even without a reviewer requesting to do so. [GPL/LGPL Appendix] > *You* think it's a bad example, *I* think it's a good example. > Fedora doesn't have a policy on this, and GNU says it's OK. Do you realise how you override what is being considered the safest and preferred way how to apply the licence terms? Just for fun? Or what makes it a good example? [compiler warnings] > Even better would be to reduce the noise in the first place. Now what sort of comment is that again? It doesn't add any value. You are not just a packager of the software, but the developer of the software. What is so difficult about developing your software with appropriate compiler flags such as -Wall -Werror? And here during review, initially you refused to acknowledge the warnings even. It required multiple comments, and still you did not even show real interest in fixing (or commenting on) at least this one: mtag.c:179: warning: format '%s' expects type 'char *', but argument 2 has type 'int' > I'm sorry, my intention here is to get my package accepted (contribute). > Later I might apply to actually be a packager if that's not too much trouble. > In any case, I was under the impression that the *first step* was to submit > a package. Reviewing comes later. A false impression then. The following page explains it: https://fedoraproject.org/wiki/Package_Review_Process [rpmlint] > It's a *warning*. I thought commenting on unimportant stuff would be > detrimental. If it was really important it wouldn't be a warning, but > an error. Splitting-hairs. As it is valid for some packages to be without documentation, one cannot turn all warnings into errors without creating false positives. Just as a rootkit checker, rpmlint wants you to add more intelligence and verify the output. What had happened actually is that rpmlint warned you -- the developer of the software -- about the total lack of documentation files. And the best you could come up with was to ignore that warning and not comment on it? > On the first try people are bound to follow the instructions, > and that's *exactly* what I did. Bugzilla is not suitable for multi-level '>', so let me point at https://fedoraproject.org/wiki/Packaging/Guidelines#Use_rpmlint once more, which is linked from many places including: https://fedoraproject.org/wiki/Package_Review_Process#Contributor The "How to get sponsored" page even gives some background as why packagers ought to become familiar with the reviewing guidelines, too: https://fedoraproject.org/wiki/PackageMaintainers/HowToGetSponsored#Reviewing_Packages > Now, let's be productive and focus on *this bug* which is > about reviewing the libmtag package. All the requirements > have been met, haven't they? If not, what's missing? An updated/fixed package to continue with. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review