Re: [boost] [review queue] What to do about the library review queue?

Subject: Re: [boost] [review queue] What to do about the library review queue?
From: degski (degski_at_[hidden])
Date: 2017-03-15 01:22:30

On 14 March 2017 at 15:53, Robert Ramey via Boost <boost_at_[hidden]>
wrote:

> "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