On 14 March 2017 at 15:53, Robert Ramey via Boost
"Only those who have managed a boost review can expect their library submissions to be to be reviewed."
And the corollary: "Only those who had their library submission accepted are eligable to be a review manager." <not related directly to the above post and rant> I don't think that $1000 'reward' is going to make any difference, so I think it's a bad idea (also for other reasons). The alternative rewards (Raffi R.) seems to me to be right from 1969, woodstock like, and we all know how that ended. I think that, as somebody in this thread (below) hinted at, if it is so hard to find a review manager (and/or people to write a review), one has to question the usefullness of that particular submission even without looking at the code. Some stuff is simply very satisfying on an intellectual level (for those sufficiently involved), but not necessarilly usefull (or useable in real life), or simply to complicated. I've been following the review of safe numerics lib closely. What strikes me is that some really fundamental criticisme comes up, the author himself states things need to be re-thought, floats are no more than an after-thought, the stated purpose of this library is ambiguous (I'm paraphrasing RR here), and still, still, reviewers vote to get it accepted. Why? I also think that in order to improve the impact of Boost, certain libraries should be retired (at least those which are now standardised). (Bigger/More is not better, Niall) Some other stuff should really go, because those libraries are really no longer of this time. I'm thinking like BGL (the manual is a book!!!), multi-array (talk about clumsy) and several others, so somebody has an opportunity and is given a challenge to create something better. Also un-maintained libs are candidates for scrapping. Boost should be like the STL (no doublettes), but obviously wider and more future oriented of course. Forget the backward compatibility (VC8, VC9, VC10, seriously. Look at Microsoft's past and learn (as they did) from them or look at Clang-4, it only compiles only with VS2015+, a deliberate choice). If one uses (a) compiler(s) that (is)/are so ancient that it doesn't come with std::array f.e., then it should be no problem to just use an old version of boost either, particularly on windows I would say, as using old compilers, means using old (and unsafe and unsupported) libraries. I am of the opinion that on windows boost should only support the compiler versions that are supported by Microsoft, then boost can move along with Microsoft (and STL) to a better future. What I also think is wrong is that in some areas there are multiple libs doing (sort of) the same thing. I should be able to go to boost.org and find THE template meta programming lib, not wade through (often terse) documentation (like presenting the library interface as "Reference Documentation", one of my favourites) of several libs and decide based on "throwing up a dime", which one I would chose (otherwise it would involve a mini review of sorts). Robert Ramey gave a presentation (Cppcon15 (16?)) regarding the process people go through picking a library. I though it was interesting, because (at the time I did not know RR was the author of the serialization lib), I went through this process and rejected his library for exactly the reasons he pointed out in his presentation, picking cereal ( https://uscilab.github.io/cereal/index.html) in stead. A one page manual, header only. I solved my problem 5 minutes later. I've never looked back. BGL no!, the same, using lemon instead... (I like food apparently :-) ) <end rant> degski