Sohail Somani wrote: [...]
If you treat warnings as errors and if bjam has an option to "keep going" as much as possible, then you get builds as far as they can go (i.e. all the warnings) and builds fail if there are warnings. Then I think you don't need to depend on the regression reporting tools for the rest of time, atleast for this stuff.
I'm convinced that library authors already make an effort to clear warnings on the platforms they have available. The real problem is dealing with platforms not available to developers. For those you do need to rely on regression reports and feedback after a tentative patch can take as long as a whole week. Furthermore I'm sure that library authors already devote to Boost all the time they can afford.
Usually the warnings I've seen in Boost are pretty easy to fix but its understandable that that puts yet another load on the developers. The "problem" with patches is that they take forever to get accepted and/or commented on as they are lots of little loads and resources are limited. Warning-fixing patches are understandably lower priority than segfault-fixing ones. Maybe a catch-all-warning-fixes bug is in order if we can get some sort of resource with commit privilege to look over it? The prerequisite is that the patches should ONLY quiet warnings.
One improvement would be to move to a bug tracking tool more manageable than sourceforge's. As a new Trac is being setup, maybe the plan is to move to its own tool, but I don't know for sure and I'm not familiar with it.
If we do this, and then at some point accept this catch-all set of patches, then we can turn on warnings as errors once the patches have been merged. I've had to do this before, and this works as far as setting you up for the future.
For how many platforms at the same time? I don't see this working unless you're able to ensure nightly regression testing turnaround for all the supported platforms. Cheers, Nicola Musatti