<rant>
I just had the most frustrating exchange with a CPAN module
developer:
Build warnings.
(Read from the bottom of the page upwards.)
This quote just about sums it all up:
That is why warnings are wanrings [sic] and no [sic] errors.
I gave him a patch, told him the correct macro to use,
and still he rejects the whole bug report. Is it me, or is
this guy just a(n) [insert appropriate pejoritive here]?
How do you convince someone that warnings are there for a
reason?
</rant>
Remember: There's always one more bug.
Re: Ignoring warnings
by brian_d_foy (Abbot) on Dec 11, 2006 at 17:56 UTC
|
Well, you certainly set him off, but you probably could have approached it a bit more friendly too:
Hey, thanks for Module::Foo. I made this change to your module to get rid of the warnings.
Tone is a difficult thing to convey in email. Honestly, you've probably worsened your position by publically implying defects in his character. That's not the way to move forward (even if you hide it behind "a CPAN developer").
Post the technical details of the patch and let shame do the rest. If the author doesn't want to change the module for whatever reason, then life sucks. Maybe he'll think about it more later and make the change, but don't push the issue to get immediate gratification. There's really nothing you can do.
| [reply] |
|
My initial posting was quite neutral in tone - just one professional conveying information to another - unless you consider the (proper) use of the word 'improper' as being unfriendly.
However, your advice is good, and I'll try to be more ingratiating in my future bug reports.
Regardless, I suppose the following is also apropos:
Never argue with an idiot. They will only pull you down to their level, then beat you with experience.
-- Brad Slipiec
Remember: There's always one more bug.
| [reply] |
|
If we're going to delve into detail, I would agree that you are right about the initial posting, though it might (or might not) have helped to explain why the cast was improper. But the follow up:
Is there some reason why you think the developers of Perl
are wrong in providing the INT2PTR macro? Do you have some
justification for not wanting to use it?
That is both confrontational and sarcastic, which is not a good strategy if you want to influence someone to do something. Now, as it happens, you're right as far as I can tell: in particular the argument that "you should not enable warnings until you really understand them" strikes me as a bit absurd. And furthermore, your correspondent falls into the rather frustrating pattern of throwing around terms like "logical fallacy" without apparently understanding what they mean. That said, he's the maintainer of the module and you're not, and as a result you're now stuck.
| [reply] |
|
Re: Ignoring warnings
by GrandFather (Saint) on Dec 11, 2006 at 19:05 UTC
|
Warnings are tricky. I fully agree that they should be cleaned up. But some times that is hard to achieve without introducing code that is obscure or fragile. That is not true in this case! There is a clear clean appropriate and informative fix. Applying it should be a no brainer.
People are tricker than warnings. At least warnings don't vacilate as their mood changes. It may be that the only way to get your (very desirable) patch applied is to eat copious quantities of humble pie, appologise profusely, and send a link to this thread.
If "typemap" is a header I would consider it essential that it "compiles clean". One of the worst things about warnings of this nature is that they hide other more important warnings by drowning them out, and that can waste a huge amount of time.
Good luck with following this issue up!
DWIM is Perl's answer to Gödel
| [reply] |
Re: Ignoring warnings
by swampyankee (Parson) on Dec 11, 2006 at 18:19 UTC
|
How do you convince someone that warnings are there for a reason?
You don't have to convince him; you just have to get him to change his behavior. Isn't there a quality rating system for CPAN modules? I don't know how thorough or how effective it is, but if "build warnings" are considered unacceptable, that may get his attention.
My personal feeling, which may be similar to yours, is that compile-time warnings are unacceptable. My experience is that they are usually the result of code that is either potentially dangerous or is not standard-compliant.
emc
At that time [1909] the chief engineer was almost always the chief test pilot as well. That had the fortunate result of eliminating poor engineering early in aviation.
—Igor Sikorsky, reported in AOPA Pilot magazine February 2003.
| [reply] |
|
You don't have to convince him; you just have to get him to
change his behavior. Isn't there a quality rating system for
CPAN modules? I don't know how thorough or how effective it
is, but if "build warnings" are considered unacceptable,
that may get his attention.
Well, it is possible to write a review against a module and
rate it. However, I have seen that venue become a vehicle for
retaliatory
activities.
Then there is CPANTS. However,
they don't build modules, leaving that activity to CPAN
testers.
As to CPAN testers, there is no criteria related to build
warnings - just 'make test' results.
So AFAIK, there is no feedback mechanism for build warnings
other than reporting them to the developer (as I did, along with a patch) with
RT being the most effective method for that purpose.
Remember: There's always one more bug.
| [reply] |
Re: Ignoring warnings
by Anonymous Monk on Dec 13, 2006 at 09:11 UTC
|
You should argue costs/benefits.
It costs nothing to change, and changing makes your code more portable (on some os/compilers they might be errors). and less warnings make you look more competent. | [reply] |
|
|