I propose to replace all of the existing warnings guidelines in the Wiki with the following: "No warnings should be emitted by Boost code. Use your best judgment to either fix or suppress the warning."
I like the simplicity of this statement of purpose, but there's value in educating developers on how to judge whether to fix or suppress a warning and in the information on how to deal with specific warnings and compiler vagaries.
If I understand correctly, you are concerned with the possibility of developers suppressing warnings as opposed to "fixing them properly."
My wording, which is indeed intended to be complete, specifically seeks to avoid such differentiation. Rather than arguing what is right and what is wrong, we should consider the simple fact that if a Boost developer suppresses a warning in a particular library, there are no reasonable grounds to require the warning to be enabled and the code "fixed".
You seem to make two assumptions: warnings are nuisances that should be ignored and all Boost authors and maintainers have sufficient knowledge to judge whether a warning should be ignored (suppressed). Neither assumption is appropriate. For the guideline to be useful, more is needed.
Warnings often indicate real problems. Sometimes they only manifest on a particular platform, revealing a portability issue. Sometimes they indicate that the code doesn't account for a runtime condition, like overflow, which the warning can only suggest as a possibility. Suppressing a warning without altering code may simply mask a problem. The right approach is to determine why the warning occurs, decide whether it is correct in the context, and if so, apply appropriate remediation. If the warning is not correct in the context, only then should it be suppressed. Your statement doesn't say even that much.
Because developers don't have the same knowledge, even among Boost developers, Boost should amass information to help them know when a warning is significant and not. That information can show cases in which a warning is legitimate and when it isn't. For the former, there can be help to understand how to change the code portably to account for the problem revealed by the warning. For the latter, there can be information on how to suppress the warning in a portable way.
I know that changing code can lead to bugs. Thus, changing code to eliminate a warning might create a bug. That's unfortunate. From a maintenance standpoint, however, I'd prefer to see altered code to a glob of preprocessor and pragma line noise that suppresses a warning in the unchanged code. Testing will reveal the bug. If it doesn't, the testing is insufficient. If the bug appears on an untested platform, then more testers are needed to be able to detect such bugs in the future.
Very elegantly put, and sums up very much how I feel as well. To put it another way, for some users, any warning *is* a bug. John.