On Fri, Nov 6, 2009 at 2:13 PM, Stewart, Robert <Robert.Stewart@sig.com> 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?
Furthermore, proving Boost quality and readiness, for a review, means meeting Boost coding policies, whatever they might be. If a potential submitter finds following a policy too onerous before a review, what might be found too burdensome after acceptance?
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.
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. Daniel