[Bug 529496] Review Request: libmtag - An advanced C music tagging library with a simple API

bugzilla at redhat.com bugzilla at redhat.com
Tue Jan 12 11:04:57 UTC 2010

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


Michael Schwendt <mschwendt at gmail.com> changed:

           What    |Removed                     |Added
                 CC|                            |mschwendt at gmail.com

--- Comment #15 from Michael Schwendt <mschwendt at gmail.com> 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
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

> 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:


> 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

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
once more, which is linked from many places including:

The "How to get sponsored" page even gives some background as why packagers
ought to become familiar with the reviewing guidelines, too:

> 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.

More information about the package-review mailing list