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 --- Comment #16 from Felipe Contreras <felipe.contreras@xxxxxxxxx> 2010-01-12 08:33:48 EST --- (In reply to comment #15) > > 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. And I followed all your suggestions that are mentioned in Fedora guidelines. > > 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: As a good sponsor you *should* leave aside your personal agendas and follow Fedora's guidelines. Of course, nobody is forcing you to do that. > 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. I am. However, I missed one link: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers > > *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? Just for fun? How about you stop assuming worst intentions? Here are a few reasons: * The text says 'library', and I often have to change it to 'program' * If the FSF changes their address (again), all the notices have to be updated (again). Having a physical mail address is completely stupid anyway (who uses physical mail anyway?) * I always have to remove ', or (at your option) any later version' just to be safe IMHO that notice is a complete waste of space. If I add it to lib/mtag.h the size will increase 30%. If I was a mindless drone I would do what everybody else does, but instead, I like to think and see what I consider "good examples" like linux, and git. And surprise! Just as I expected, they don't enforce these notices. You are free to think that linux, git, and libmtag are "bad examples", but that's *your* opinion, so please treat it as such. > > 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' WTF are you talking about? My first reply (comment #3) was: I didn't get those warnings, but I'll changes the CFLAGS to catch them in the future, and I'll fix them. What you are saying is not true. > > 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 I have re-read that text many times, but until now I found this link: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers I didn't know as a Contributor I was supposed to join as maintainer. > > 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? I did consider the warnings and I chose not to comment on them, just like I do when I ignore checkpatch warnings for lines bigger than 80 characters. Now, if you do want me to comment on the lack of documentation of the 'tools' package, I would rather remove it. And for the 'devel' package, well I'm a big believer in self-documenting code, and an API that's 48 lines of code (including notices and extra chunk), I think it doesn't require any documentation. > > 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 Yeah, I followed that; I used rpmlint as mentioned. However, it's not mentioned that I need to provide the output. Sure, it's mentioned somewhere else, but not there. > 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 Yeah, but as I said before, I didn't know I *had* to be following the procedure to become a maintainer as of now. > > 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. And what needs fixing? As I mentioned in comment #19; everything has been addressed upstream... there's no need to update the spec file. -- 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