----- Original Message ----- From: "Phil Endecott" <spam_from_boost_dev@chezphil.org> To: <boost@lists.boost.org> Sent: Tuesday, January 06, 2009 11:44 PM Subject: Re: [boost] Futures Review Starts Today - January 5, 2009
One of the things that Boost tries to be is a proving-ground for things that are heading towards C++ standardisation. In this case it seems to have gone topsy-turvy: the C++ standards committee have approved an implementation of futures and now Boost is reviewing two libraries neither of which is an exact implementation of the standard proposal. This doesn't seem right to me. So:
- The idea of futures looks useful and I think Boost should have it.
I agree completly.
- It would not be sensible to have anything other than something conforming to the proposed standard, except for any hacks necessary for pre-0x compatibility and perhaps for non-conflicting extra features.
I agree again.
- I believe that both of the proposals were ready for review some time ago. I'm unsure of the exact chronology but I have the impression that if they had been reviewed by Boost more promptly then perhaps that review could have been available to the standards committee.
I think this was the intention of Anthony.
- I understand that the slowness of the review queue is a result of too few review managers for too many proposed libraries. Assuming that the pool of review managers can't be pressed to give up more of their time, maybe the pool could be widened by relaxing the required qualifications: although reviews often require that the review manager does a lot of collating of opinions, I'm not aware of many cases where the essential accept/reject decision has been very difficult to make or is different from what a vote-count of reviewers would have said (though maybe I'm wrong).
Where can we found the required qualifications of a review manager?
Alternatively maybe the other end of the problem should be fixed by attempting to limit the scope of contributions to focus more on "core" features that might one day end up in std::c++.
Which Boost libraries can not one day end up in std::c++? In any case I don't thik this limitation will be useful. Best, Vicente