Re: [boost] Official warnings policy?

Subject: Re: [boost] Official warnings policy?
From: Daniel James (daniel_james_at_[hidden])
Date: 2009-11-11 16:11:38

2009/11/9 Stewart, Robert <Robert.Stewart_at_[hidden]>:
> If reviewers are expected to judge code quality and it produces myriad
> warnings with established warnings settings, what might reviewers conclude?

That it was developed with a different compiler or with different
settings? Warnings are useful tool, but they aren't necessary or
sufficient for quality. Would you really reject a library because of
unreferenced parameters? Shouldn't a reviewer be looking at more
meaningful indicators of quality (eg. documentation, test coverage).

> There could be a required evaluation step after the usual review to provide
> final acceptance.  That would make it easier to accept warnings in a library
> under review.  If the author does not meet the (not yet) established warnings
> policy after a tentative review acceptance but before final acceptance, then
> it would be rejected.  I assume that such a two-stage review process would be
> fairer in your mind?

We already have something like that. Before a new library can be
merged to the release branch it has to be approved by the release
managers. One of the criteria is decent regression test results. So if
we had regression tests running with warnings as errors, this would be
checked before release.

> That subjective evaluation reflects your view that compiling with zero
> warnings has no bearing on code quality.  Others have a differing view.

Since you want extra requirements added to the review process, it's
actually up to you to demonstrate that requiring warning free code
will be sufficiently beneficial. So just saying that my views are
subjective is not enough. And the thing is, I've also got a fine
counter-example, Boost itself.

> If Boost makes zero warnings a goal for all libraries and a requirement for
> all new libraries, at established warnings settings, then it will be because
> there is consensus that there is value in so doing, regardless of individual
> notions.

The main reason we're working on warning free code is so that users
who like to compile with warnings on won't have a lot of distracting
noise in their compiler's output. Which is surely only a requirement
at the time of release.

Daniel