Re: [boost] Official warnings policy?

Subject: Re: [boost] Official warnings policy?
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2009-11-09 09:27:22

Daniel James wrote:
> On Fri, Nov 6, 2009 at 2:13 PM, Stewart, Robert
> <Robert.Stewart_at_[hidden]> wrote:
> > Daniel James wrote:
> >>
> >> Currently, we don't even require that a library builds on
> >> any specific
> >> compilers, let alone warning free. What you're suggesting adds a
> >> considerable burden on a developer - which is particularly
> >> unfair if
> >> the library is eventually rejected. Implementation issues
> >> can be fixed
> >> after the review and, in this case, I would hope it would
> >> be with the
> >> help of the boost community.
> >
> > It isn't unfair if the submitter understands a policy a priori.
>
> How does understanding an unfair burden in advance make it fair?

Determining whether a policy is unfair is subjective.  If one considers, in this case, that zero warnings at some Boost-established warnings setting is important to demonstrating code quality and to make the job of reviewers as easy as possible, then it is a fair policy.  If reviewers are expected to judge code quality and it produces myriad warnings with established warnings settings, what might reviewers conclude?

When a potential library submitter evaluates Boost policies, those policies may be considered too onerous or not.  If the former, Boost might be denied a useful library, but the denial wasn't unfair.  All submitters face the same policies and choose whether to accept them.  Whether a policy is well or ill conceived can be determined more objectively than can its fairness.

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?

> Supporting setups other than your own is much easier after
> acceptance as
> you have access to the testing system and the support of the
> community.

The requirement might be levied for a single compiler in order to submit a library for review.  That would demonstrate the ability to meet the requirement without putting an undue burden on the developer.  However, libraries are strongly encouraged to demonstrate portability by working successfully with multiple compilers.  Thus, if a library claims to support a set of compilers, then it would be reasonable to expect the same warnings policy to apply to each such compiler.

> > Whether such a warnings policy is ever made official is completely
> > separate; whatever policies are established, it is fair to expect
> > submitters to follow them
>
> Not really, if those policies have no bearing on the quality of the
> library then they don't have to be a review requirement. They
> can be met
> between review and release. Requiring warning free code at the review
> is just box ticking.

That subjective evaluation reflects your view that compiling with zero warnings has no bearing on code quality.  Others have a differing view.  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.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.