Boost logo

Boost :

From: Jeff Garland (azswdude_at_[hidden])
Date: 2020-06-27 03:46:24


On Fri, Jun 26, 2020 at 7:02 PM Zach Laine via Boost <boost_at_[hidden]>
wrote:

>
> I don't know how this would work exactly, and I find it concerning
>

I don't either, but I think we should ponder it. At a basic level maybe
some folks would volunteer to help an author 'boostify' a library. Maybe
summer of code projects.

> that we would essentially have a lower bar for stuff that is targeting
> the standard, where it will eventually be chiseled into stone.
>

As you know, that is exactly the opposite of what I think -- if anything we
should raise the bar. Part of that is on the committee itself to learn how
to reject. And yet, it's clear that Ranges and Format aren't some half
baked idea -- and yet not via Boost. Of course, Networking will likely be
the next big addition from Boost -- let's see adopted int Boost 1.36.
We're running out of decade+ old libraries to influence the standard.

> However, where we might improve would be in lowering the bar to entry
> required just to submit a library for review. These hurdles currently
> exist:
>
> - This list is not very welcoming. One committee proposal I know of
> that is exactly the right kind of thing for Boost did not submit to
> Boost because they felt this list was rude and combative. I don't
> know the details, so I don't know if this particular complaint is
> warranted. More generally, this list is hard for outsiders to
> penetrate; pretty good evidence for this is the fact that we have
> posts here mostly from the usual suspects, and new voices don't appear
> very often. I have no suggested fixes for this, unfortunately.
>

Yes, this is unfortunate, and I likewise have no solution.

- It can be hard to figure out how to submit to Boost, and once you
> do, the process is pretty involved. We've addressed part of this by
> having a list of names of Boosters who have volunteered to act as
> review managers for stuff targeting the standard. Having yet more
> people volunteer to walk people through the process, and/or better
> document the process, would help here. As one example, is getting
> endorsements actually necessary? The submission process page says
> that it is, but that step seems to be skipped pretty often from what I
> can tell. Maybe I'm just not paying enough attention.
>

idk if this is the main issue, but certainly might play a role.

> - The build system and other infrastructure is unlike anything
> anywhere else, and super obscure, because it is not documented well
> enough to do anything but copy/paste from an existing Boost lib. We
> could of course use something that is used more widely.
>

There seems to be in progress at some level toward cmake -- but really it's
not that hard to adapt.

> I want to see more std lib proposals come through Boost first, and I
> think a lot of you do, too.

Not a question in my mind on that.

> However, for that to happen at a larger
> scale than what we're seeing today (which is me alone as far as I can
> tell), we would need to sand off those rough edges I mentioned. The
> status quo is that it's simply so much easier to submit straight to
> LEWG that only a crazy person would do otherwise (again, that would be
> me).
>

I'm afraid you are correct, which is why I brought it up. Maybe I'm
channeling Dave A and Beman here -- but I think self reflection is in
order.

I'm not willing to do this work. I have too many irons in the fire as
> it is working on committee stuff and Boost libs. Perhaps someone here
> will be sufficiently motivated to address some of these things.
>

I agree -- you're one of the few doing it right. I'm only opening a
discussion here so that maybe the dynamic can change.

Jeff


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk