(A new subject, since the thread has evolved past the Text review result). I spend part of my time in the C++ standards committee. I spend part of my time in Boost. I would prefer that my time spent in Boost, and that Boost itself, be focused on its goals of serving the C++ community and Boost users (existing ones, and growing to new ones). If there is benefit of Boost to any other entity, be it the LEWG of the committee, or some organization, that's great. i.e. When Boost is adopted by some organization, or when Boost components go into the standard, that's just a bonus. But Boost itself shouldn't compromise on quality - in its review process or what it ships in a Boost distribution, to serve any of those other interests. Putting a bunch of experimental libraries into a Boost release just because people have proposed them for standardization is not something we should do. If someone wants to, they can should just start their own project full of libraries that have not undergone any kind of formal review, and convince OS distributions to start including that as part of their packages based on its own merits. In case there was any misunderstanding on this point: Zach's goals of standardization are his own, and in Boost we don't have to be concerned with them. Because we're not changing the review process because of them, and he's not asking us to. Glen
On Sat, Jun 27, 2020 at 9:02 AM Glen Fernandes via Boost < boost@lists.boost.org> wrote:
(A new subject, since the thread has evolved past the Text review result).
Agree, thanks.
I spend part of my time in the C++ standards committee. I spend part of my time in Boost.
Many of us do.
If there is benefit of Boost to any other entity, be it the LEWG of the committee, or some organization, that's great. i.e. When Boost is adopted by some organization, or when Boost components go into the standard, that's just a bonus.
It used to not just be a bonus -- it's the prime reason Boost exists. If it no longer has that mission we should make that clearer.
But Boost itself shouldn't compromise on quality - in its review process or what it ships in a Boost distribution, to serve any of those other interests.
That is a decision for the Boost community to make, while there is still a community. If all C++ library development goes elsewhere then there won't be much left.
Putting a bunch of experimental libraries into a Boost release just because people have proposed them for standardization is not something we should do.
I disagree. Consider how painful it is for a c++ programmer that wants to contribute to the review proposed libraries for the C++ standard. And by that I mean, go and use the implementation. In my case I was doing this for c++20 -- it was super painful. Aside from the time it took to go pull from different places, compiler support and library quality/robustness was all over the map. In the past, when 90% of the things went thru Boost this meant downloading Boost and going to town. When TR1 came there was a special Boost package for it. The regression system would let you know where it worked and where it didn't. If someone wants to, they can should just start their own project full
of libraries that have not undergone any kind of formal review, and convince OS distributions to start including that as part of their packages based on its own merits.
As you know well, the proposals for the standard are undergoing a formal review, it's just not a Boost review. And just so my intention is clear -- my goal is to increase the review of the proposals that make it into the standard. In my opinion the bar too the standard needs to be raised a couple more levels. After sleeping on it I like the idea more than ever -- so maybe I'll work on it. And if Boost doesn't want to distribute it then it's more of the same mind share drain away from Boost. I think it would be fine to ship the proposed elements outside the main distro until it went thru a normal review. Ideally we'd get more authors to submit to a boost review and come under the tent. Maybe we could have some of the 'boostification' work done by Summer of Code students. Maybe this will led to more libraries like asio that can ship standalone and in Boost as well. In case there was any misunderstanding on this point: Zach's goals of
standardization are his own, and in Boost we don't have to be concerned with them. Because we're not changing the review process because of them, and he's not asking us to.
Understood, but we should care about his effort to standardize. Unicode is hard, it's a mess in C++, and average programmers could use a Boost (sorry, so sorry, not sorry :). Ideally what Zach proposes will ship under the Boost banner first. Why? So more than the maybe 20 people on the committee will look at it before the ink is dried and it ships with compilers. Jeff
On Sat, Jun 27, 2020 at 3:46 PM Jeff Garland via Boost <boost@lists.boost.org> wrote:
Ideally what Zach proposes will ship under the Boost banner first. Why? So more than the maybe 20 people on the committee will look at it before the ink is dried and it ships with compilers.
It sounds like the committee's workflow is defective. If more people should interact with the library before it goes into the standard, here's a novel idea: Don't put it in the standard yet. Why does Boost.Text have to go into the standard right away? Why can't it enjoy life as its own non-std library for a few years, the way that Asio did? Plenty of users and companies can enjoy the Unicode library without it having to be in the std:: namespace. Thanks
On Sat, Jun 27, 2020 at 4:12 PM Vinnie Falco <vinnie.falco@gmail.com> wrote:
On Sat, Jun 27, 2020 at 3:46 PM Jeff Garland via Boost <boost@lists.boost.org> wrote:
Ideally what Zach proposes will ship under the Boost banner first. Why? So more than the maybe 20 people on the committee will look at it before the ink is dried and it ships with compilers.
It sounds like the committee's workflow is defective. If more people
It has defects like any other process -- there is no perfect approach. And plenty of committee members agree (as you can see many on this list are involved). In general, the committee responds only to people that bring proposals -- that can be members of the committee or anyone in the community. If you write a paper and propose something the committee will respond. should interact with the library before it goes into the standard,
here's a novel idea:
Don't put it in the standard yet.
That's correct, I really wish it were this easy. So one of the 1st questions a library will face is: is there an implementation? And the obligatory github repo is provided (do we go download and compile it - who has the time?). Next typical question: Given the priorities of the committee for the next release, do we want to spend time on this proposal? I'm sure a few proposals fail this bar, but probably not nearly enough. Part of the issue there being that c++ is forever behind in basic standard library facilities compared to other languages - we still have technical debt. Of course that isn't it -- if your library proposal is small you have to make it through a design study group, Library Evolution, and finally LWG. It would be typically a ~2 year process. You'd think that would afford plenty of time for committee members to look at the details, but the world is full of distractions. If it's bigger....well read on...
Why does Boost.Text have to go into the standard right away?
It doesn't, and I'd be personally surprised if it makes 23 (sorry Zach).
Why can't it enjoy life as its own non-std library for a few years, the way that Asio did?
Many apologies to Chris K. on that from me (fun fact I was asio review manager). Without checking, I think over a decade of his life has expired working toward getting asio into the standard. All of us owe Chris a huge debt of gratitude for the endless hours he's spent.
Plenty of users and companies can enjoy the Unicode library without it having to be in the std:: namespace.
While true, it's still very much surprising how many cannot. Being in std:: really is the ultimate c++ distro. Jeff
On Sat, Jun 27, 2020 at 4:36 PM Jeff Garland <azswdude@gmail.com> wrote:
Being in std:: really is the ultimate c++ distro.
Yes well this attitude needs to change as it is obviously unsustainable. Lowering Boost's acceptance bar doesn't sound like a good way to solve this. Until this problem is addressed (among other things) I prefer to do other more productive things, as the return on my time investment in committee matters is lower than alternatives. Thanks
On Sun, Jun 28, 2020 at 12:24 PM Vinnie Falco wrote:
On Sat, Jun 27, 2020 at 4:36 PM Jeff Garland wrote:
Being in std:: really is the ultimate c++ distro.
Yes well this attitude needs to change as it is obviously unsustainable. Lowering Boost's acceptance bar doesn't sound like a good way to solve this.
+1. Boost is a peer reviewed collection of libraries. Boost's success has come from that peer review. Just because Boost.X was peer reviewed and has built user trust, sticking a "Boost." in front of "Y" to form "Boost.Y" just because Y is proposed for the standard isn't right. If "Y" wants to be part of Boost and be "Boost.Y", it should be formally reviewed. Now if you want to have "BoostExperimental.Y" then make a new project called BoostExperimental but let's not shovel anything into the Boost release distribution that wasn't peer reviewed. If the problem being solved is unacceptable things being put into the C++ standard library, and the idea is having them go through Boost first, I like that. But that should mean going through Boost's formal review process. Not being exempt just because they were proposed for the standard. The pathological case scenario is Boost's reputation and quality being diminished and consequently Boost not being a viable means for those proposed libraries to get user experience anyway. Glen
On Sun, 28 Jun 2020 at 19:40, Glen Fernandes via Boost <boost@lists.boost.org> wrote:
On Sun, Jun 28, 2020 at 12:24 PM Vinnie Falco wrote:
On Sat, Jun 27, 2020 at 4:36 PM Jeff Garland wrote:
Being in std:: really is the ultimate c++ distro.
Yes well this attitude needs to change as it is obviously unsustainable. Lowering Boost's acceptance bar doesn't sound like a good way to solve this.
+1.
Boost is a peer reviewed collection of libraries. Boost's success has come from that peer review.
Just because Boost.X was peer reviewed and has built user trust, sticking a "Boost." in front of "Y" to form "Boost.Y" just because Y is proposed for the standard isn't right.
If "Y" wants to be part of Boost and be "Boost.Y", it should be formally reviewed.
Now if you want to have "BoostExperimental.Y" then make a new project called BoostExperimental but let's not shovel anything into the Boost release distribution that wasn't peer reviewed.
If the problem being solved is unacceptable things being put into the C++ standard library, and the idea is having them go through Boost first, I like that. But that should mean going through Boost's formal review process. Not being exempt just because they were proposed for the standard.
The pathological case scenario is Boost's reputation and quality being diminished and consequently Boost not being a viable means for those proposed libraries to get user experience anyway.
Fully agreed. Lowering the bar of getting something into Boost doesn't help anyone. Some standard proposals come with the statement "this has been accepted into Boost", and some with "this has been shipping in Boost for N years". Those are useful bits of information. They become useless bits of information if Boost starts accepting libraries without peer review. They become worse than useless if Boost starts accepting libraries just because they are in the standard pipe, and I don't think anyone has suggested that. Boost can be a step on the way to include a library into the standard. But it should be such a step if and only if the expected-quality peer review that we've come to expect from Boost takes place. Boost is also not only such a step, it's more than that, so it shouldn't be subservient to the purposes of standardizing library proposals.
On Sun, Jun 28, 2020 at 11:40 AM Glen Fernandes via Boost <boost@lists.boost.org> wrote:
On Sun, Jun 28, 2020 at 12:24 PM Vinnie Falco wrote:
On Sat, Jun 27, 2020 at 4:36 PM Jeff Garland wrote:
Being in std:: really is the ultimate c++ distro.
Yes well this attitude needs to change as it is obviously unsustainable. Lowering Boost's acceptance bar doesn't sound like a good way to solve this.
+1.
Boost is a peer reviewed collection of libraries. Boost's success has come from that peer review.
Just because Boost.X was peer reviewed and has built user trust, sticking a "Boost." in front of "Y" to form "Boost.Y" just because Y is proposed for the standard isn't right.
If "Y" wants to be part of Boost and be "Boost.Y", it should be formally reviewed.
Now if you want to have "BoostExperimental.Y" then make a new project called BoostExperimental but let's not shovel anything into the Boost release distribution that wasn't peer reviewed.
If the problem being solved is unacceptable things being put into the C++ standard library, and the idea is having them go through Boost first, I like that. But that should mean going through Boost's formal review process. Not being exempt just because they were proposed for the standard.
The pathological case scenario is Boost's reputation and quality being diminished and consequently Boost not being a viable means for those proposed libraries to get user experience anyway.
Raising issue on this list with the way WG21 does things accomplishes nothing. Our choices as a separate Boost entity are: 1) get involved directly and individually with WG21 and fix things, for our individual definitions of "fix"; and 2) accept the reality that WG21 actually wants to move even faster than it already does* and make it easier for Boost to accept new libraries before they are standardized, thereby influencing the quality of those submissions. * Based on polling of WG21 members at multiple WG21 meetings in the last 2 years. #1 relies on individual effort and ability. Some cannot get the time off for, or cannot afford, or cannot stand the process enough, to attend WG21 meetings. #2 is change we can actually effect. The shape of that does not have to be exactly what Jeff has proposed -- that's just one suggestion. There is a perception among WG21 submitters that Boost is an opaque and unwelcoming organization, whether deserved or not. I don't personally find it to be so, and maybe this is simply intellectual intimidation as others in this thread have suggested. Nevertheless, that and certain technical considerations (Boost.Build for one) prevent people from going through the hassle of submitting to Boost before WG21. I think we should focus on smoothing that process in whatever way we think would be effective, if we want the output of WG21 to be better, without getting directly involved with WG21. Zach
On Sun, Jun 28, 2020 at 11:56 AM Zach Laine via Boost <boost@lists.boost.org> wrote:
Raising issue on this list with the way WG21 does things accomplishes nothing. Our choices as a separate Boost entity are: 1) get involved directly and individually with WG21 and fix things, for our individual definitions of "fix"; and 2) accept the reality that WG21 actually wants to move even faster than it already does* and make it easier for Boost to accept new libraries before they are standardized, thereby influencing the quality of those submissions.
I disagree. Boost does not need to do anything, the problem we're discussing is a committee problem. Whether they see it this way or not, this is the truth. As long as the committee is willing to "standardize" innovation -- and there's no indication that they intend to stop, if anything the process is accelerating -- there is nothing we can do to have library authors go through the hassle of Boost. Specifically, it is not clear to me that the lower volume of Boost activity is a problem, nor I think we need to attract the kind of developer who views Boost as an obstacle to getting their library standardized ASAP. This isn't something that can be fixed from within. The last thing we should be doing is lower the bar in Boost.
On Sun, Jun 28, 2020 at 2:42 PM Emil Dotchevski via Boost <boost@lists.boost.org> wrote:
On Sun, Jun 28, 2020 at 11:56 AM Zach Laine via Boost <boost@lists.boost.org> wrote:
Raising issue on this list with the way WG21 does things accomplishes nothing. Our choices as a separate Boost entity are: 1) get involved directly and individually with WG21 and fix things, for our individual definitions of "fix"; and 2) accept the reality that WG21 actually wants to move even faster than it already does* and make it easier for Boost to accept new libraries before they are standardized, thereby influencing the quality of those submissions.
I disagree. Boost does not need to do anything, the problem we're discussing is a committee problem. Whether they see it this way or not, this is the truth.
I agree that this is a WG21 problem. It *is* the truth. But so what? What does knowing that truth actually do? If WG21 does not see things this way, the fact that it is the truth is irrelevant. Many people have raised this issue in WG2 meetings. It has fallen on deaf ears, for a variety of reasons. Again, knowing the truth and revealing it on a mailing list will not change the behavior in the LEWG meeting room.
As long as the committee is willing to "standardize" innovation -- and there's no indication that they intend to stop, if anything the process is accelerating -- there is nothing we can do to have library authors go through the hassle of Boost.
Here I disagree. I've had several people ask me how to submit things to Boost in WG21 meetings, and I've given them a rundown, and offered some degree of hand-holding. When only one of them (JeanHeyd) actually followed through, I asked the others why they did not. I got answers in line with the suggested changes I've mentioned in this discussion. Those changes won't get all WG21 submitters to use Boost, but I think it will be better than 1/N. Also, regaining the reputation as *the* proving ground for future standard libraries would help too. That relies partially on getting WG21 submitters' involvement, but also on doing as Jeff suggested earlier -- having backported items from C++X in Boost for use in C++<X. Note that all of these measures would enable more people to submit to Boost, whether they were WG21 participants or not.
Specifically, it is not clear to me that the lower volume of Boost activity is a problem
We seem to be getting lower and lower numbers of reviewers. I think that's a problem, and I think increasing the number of active participants may help solve that (or at least I hope so).
, nor I think we need to attract the kind of developer who views Boost as an obstacle to getting their library standardized ASAP.
I care about the quality of submissions to Boost, and I don't want to lower that regardless of what WG1 does or does not do. I also care about stopping untested library additions from moving through LEWG. I think Boost *could* be a partial solution to that. I don't think those goals need to be at odds.
This isn't something that can be fixed from within. The last thing we should be doing is lower the bar in Boost.
You're talking about two different things. We can make it easier to get into Boost (overcoming technical obstacles and better documenting the process) without lowering the quality bar for reviews. Zach
On Sun, Jun 28, 2020 at 1:32 PM Zach Laine via Boost <boost@lists.boost.org> wrote:
Specifically, it is not clear to me that the lower volume of Boost activity is a problem
We seem to be getting lower and lower numbers of reviewers. I think that's a problem, and I think increasing the number of active participants may help solve that (or at least I hope so).
I agree that lower number of reviewers is a problem. I meant that it is not clear if a lower number of submissions is a problem.
, nor I think we need to attract the kind of developer who views Boost as an obstacle to getting their library standardized ASAP.
I care about the quality of submissions to Boost, and I don't want to lower that regardless of what WG1 does or does not do. I also care about stopping untested library additions from moving through LEWG. I think Boost *could* be a partial solution to that. I don't think those goals need to be at odds.
They are not at odds, they're orthogonal. Realistically, I think that the committee will continue to "standardize" innovation, and there's nothing that can be done to stop that (I'd love to be proven wrong). Independently, we can work to make Boost better, though I am not sure how. I agree that the mailing list is archaic, but it works great, and I don't think it's an obstacle for anyone. Perhaps I'm wrong about this.
On Sun, Jun 28, 2020 at 9:19 PM Emil Dotchevski wrote:
Independently, we can work to make Boost better, though I am not sure how. I agree that the mailing list is archaic, but it works great, and I don't think it's an obstacle for anyone. Perhaps I'm wrong about this.
The concrete items mentioned that have been known to inhibit participation appear to be: - Mailing lists - Boost.Build Not sure what to do about the second. I'm happy to help anyone (LEWG or otherwise) produce Jamfiles for their prospective libraries for building, testing, and documentation generation (if Doxygen, Asciidoc). Glen
On Sun, Jun 28, 2020 at 8:26 PM Glen Fernandes via Boost < boost@lists.boost.org> wrote:
The concrete items mentioned that have been known to inhibit participation appear to be: - Mailing lists - Boost.Build
Not sure what to do about the second.
It's easy.. Make it abundantly clear that a build system, *any* build system, is expected or required for review. And one way to do that is to *require* no build system for review. Because if your library can be reviewed easily without a build system it means the portability of your code is good. Anything else should be a red flag for reviewers. PS. I'll keep living the dream when we don't distribute any build system with our libraries. Or the alternate dream where we distribute with 5 or more alternate build system specifications. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net
On Sun, Jun 28, 2020 at 6:50 PM René Ferdinand Rivera Morell via Boost < boost@lists.boost.org> wrote:
On Sun, Jun 28, 2020 at 8:26 PM Glen Fernandes via Boost < boost@lists.boost.org> wrote:
The concrete items mentioned that have been known to inhibit participation appear to be: - Mailing lists - Boost.Build
Not sure what to do about the second.
It's easy.. Make it abundantly clear that a build system, *any* build system, is expected or required for review. And one way to do that is to *require* no build system for review. Because if your library can be reviewed easily without a build system it means the portability of your code is good. Anything else should be a red flag for reviewers.
PS. I'll keep living the dream when we don't distribute any build system with our libraries. Or the alternate dream where we distribute with 5 or more alternate build system specifications.
Perhaps we should require travis and appveyor for review, and nothing else.
On 2020-06-29 04:49, René Ferdinand Rivera Morell via Boost wrote:
On Sun, Jun 28, 2020 at 8:26 PM Glen Fernandes via Boost < boost@lists.boost.org> wrote:
The concrete items mentioned that have been known to inhibit participation appear to be: - Mailing lists - Boost.Build
Not sure what to do about the second.
It's easy.. Make it abundantly clear that a build system, *any* build system, is expected or required for review. And one way to do that is to *require* no build system for review. Because if your library can be reviewed easily without a build system it means the portability of your code is good. Anything else should be a red flag for reviewers.
PS. I'll keep living the dream when we don't distribute any build system with our libraries. Or the alternate dream where we distribute with 5 or more alternate build system specifications.
Assuming the library requires separate compilation, a build system is needed for the library to be usable. Reviewing and accepting a library that is not usable makes no sense. Furthermore, in order for users to be able to use Boost, they need a way to build it, that is compile and install artifacts of every library in a common place. There needs to be a common interface for doing this. Currently, this is achieved by Boost.Build, so any new library has to integrate with it. If it uses a different build system internally, it must at least support being invoked from Boost.Build. Without this user experience will be severely hampered. I'm not insisting that Boost.Build should be that common user interface for building Boost, but there must be one. I'm not attached to Boost.Build specifically - any build system that is able to handle building and testing Boost, including docs, would do. However, personally I'm opposed to having mode than one build systems per library, as that unnecessarily increases maintenance burden.
On Mon, Jun 29, 2020 at 3:47 AM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
On 2020-06-29 04:49, René Ferdinand Rivera Morell via Boost wrote:
On Sun, Jun 28, 2020 at 8:26 PM Glen Fernandes via Boost < boost@lists.boost.org> wrote:
The concrete items mentioned that have been known to inhibit participation appear to be: - Mailing lists - Boost.Build
Not sure what to do about the second.
It's easy.. Make it abundantly clear that a build system, *any* build system, is expected or required for review. And one way to do that is to *require* no build system for review. Because if your library can be reviewed easily without a build system it means the portability of your code is good. Anything else should be a red flag for reviewers.
PS. I'll keep living the dream when we don't distribute any build system with our libraries. Or the alternate dream where we distribute with 5 or more alternate build system specifications.
Assuming the library requires separate compilation, a build system is needed for the library to be usable. Reviewing and accepting a library that is not usable makes no sense.
All users already have a build system. Most have it in the form of an IDE. It should be trivial to add the library's source files to your own build system for review purposes. If the library design makes that hard it should be a red flag.
Furthermore, in order for users to be able to use Boost, they need a way to build it, that is compile and install artifacts of every library in a common place. There needs to be a common interface for doing this. Currently, this is achieved by Boost.Build, so any new library has to integrate with it. If it uses a different build system internally, it must at least support being invoked from Boost.Build. Without this user experience will be severely hampered.
That can happen after acceptance. Expecting libraries to use B2, or any particular build system, for review increases the barrier of entry.
[snip]
However,
personally I'm opposed to having mode than one build systems per library, as that unnecessarily increases maintenance burden.
Having more than one build system in your library reduces the friction for users. Hence it increases the set of likely users. I think that's worth the maintenance burden. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net
On 2020-06-29 15:37, René Ferdinand Rivera Morell wrote:
On Mon, Jun 29, 2020 at 3:47 AM Andrey Semashev via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org>> wrote:
All users already have a build system. Most have it in the form of an IDE. It should be trivial to add the library's source files to your own build system for review purposes. If the library design makes that hard it should be a red flag.
Having the world compiled along with your application is one possible use case, but certainly not the only one. Many of us prefer to build external dependencies separately and only once instead of every time with the application. One point where putting external sources in your project doesn't work is configure-time checks, which are implemented in the library build system. I see nothing wrong with such checks, and don't consider them a "red flag".
Furthermore, in order for users to be able to use Boost, they need a way to build it, that is compile and install artifacts of every library in a common place. There needs to be a common interface for doing this. Currently, this is achieved by Boost.Build, so any new library has to integrate with it. If it uses a different build system internally, it must at least support being invoked from Boost.Build. Without this user experience will be severely hampered.
That can happen after acceptance. Expecting libraries to use B2, or any particular build system, for review increases the barrier of entry.
It prevents reviewers from trying out the library. It might also suggest that the library have not been built or tested prior to the review.
[snip]
However, personally I'm opposed to having mode than one build systems per library, as that unnecessarily increases maintenance burden.
Having more than one build system in your library reduces the friction for users. Hence it increases the set of likely users. I think that's worth the maintenance burden.
Well, let's just say I disagree.
On Mon, Jun 29, 2020 at 7:58 AM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
On 2020-06-29 15:37, René Ferdinand Rivera Morell wrote:
On Mon, Jun 29, 2020 at 3:47 AM Andrey Semashev via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org>> wrote:
All users already have a build system. Most have it in the form of an IDE. It should be trivial to add the library's source files to your own build system for review purposes. If the library design makes that hard it should be a red flag.
Having the world compiled along with your application is one possible use case, but certainly not the only one. Many of us prefer to build external dependencies separately and only once instead of every time with the application.
After *acceptance* use a package manager.
One point where putting external sources in your project doesn't work is configure-time checks, which are implemented in the library build system. I see nothing wrong with such checks, and don't consider them a "red flag".
I see them as a red flag.
Furthermore, in order for users to be able to use Boost, they need a way to build it, that is compile and install artifacts of every library in a common place. There needs to be a common interface for doing this. Currently, this is achieved by Boost.Build, so any new library has to integrate with it. If it uses a different build system internally, it must at least support being invoked from Boost.Build. Without this
user
experience will be severely hampered.
That can happen after acceptance. Expecting libraries to use B2, or any particular build system, for review increases the barrier of entry.
It prevents reviewers from trying out the library. It might also suggest that the library have not been built or tested prior to the review.
It would be rather unlikely for that to be the case given the preceding history of a library before getting to the review stage.
[snip]
However, personally I'm opposed to having mode than one build systems per library, as that unnecessarily increases maintenance burden.
Having more than one build system in your library reduces the friction for users. Hence it increases the set of likely users. I think that's worth the maintenance burden.
Well, let's just say I disagree.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net
René Ferdinand Rivera Morell wrote:
Expecting libraries to use B2, or any particular build system, for review increases the barrier of entry.
It does, and I consider this a feature. Writing a Jamfile or two is trivial (if indeed your library is a bag of source files and it doesn't need to f.ex. link to OpenSSL or detect AVX-512 at configure time.) Refusing to do so is a deliberate slight. Same would apply to CMake by the way; having a submodule-friendly CMakeLists.txt should be a requirement, and will indeed also increase the barrier of entry. So far, 0% of the libraries having a CMakeLists.txt file have been usable as a submodule.
The concrete items mentioned that have been known to inhibit participation appear to be: - Mailing lists
First. Thank you to everyone that continues to make, and has made, Boost what it is and what it has provided. It takes an inordinate amount of effort to produce quality and those efforts are under recognized and not overtly appreciated often enough. I'm a ML lurker and haven't contributed to any review[*], so probably not the target audience and hence the [OT], but as a method for consuming and very occasionally participating, the mailing list is the perfect medium. It's an invaluable resource for me to keep my thumb on what the issues are and what is coming down the pipe in new standards and features. I know that forums can be subscribed to in concept, but so far, I've just stopped following when the switch happens. A recent example is sqlite. Quite honestly, web interfaces are too obtrusive for this type of content probably because I don't 'live' in a browser during my normal computer time, a shell prompt ssh'ed to another shell. My suggestion is that before turning off the ML, if not already done, collect some data and follow up with some projects that have done that and see if the results Boost desires manifested after changing to forums. My speculation is that changing from ML to forums mostly reduces to the preference/enthusiasm of the person that is maintaining that part of the infrastructure much more so than results it produces. I've observed a similar conversation happening in a number of technical mailing lists and suspect there is something broader happening in industry that results in these types of conversations, but not sure what it is exactly. Maybe just advancements in Github capabilities. [*] I've not contributed to any review because I'm not expert enough C++ or in the topic of the library under review. Often there a dozen or more acronyms, special cases, etc that the experts on this list do realize and have the ability to scrutinize. I'm appreciative and grateful for the quality that this ensures and learn quite a bit following along, but that doesn't make me qualified to do a review and in my mind, doing so would just be wasting other experts scarce time.
On Sun, Jun 28, 2020 at 10:22 PM Schrom, Brian T via Boost <boost@lists.boost.org> wrote:
My suggestion is....
Yeah mailing lists are nice for the monotonically decreasing set of older engineers used to the anachronism but they are not in any way shape or form attractive for bringing in new, young blood. Thanks
On 2020-06-29 08:40, Vinnie Falco via Boost wrote:
On Sun, Jun 28, 2020 at 10:22 PM Schrom, Brian T via Boost <boost@lists.boost.org> wrote:
My suggestion is....
Yeah mailing lists are nice for the monotonically decreasing set of older engineers used to the anachronism but they are not in any way shape or form attractive for bringing in new, young blood.
Hopefully, the young blood will mature one day and realize the convenience of the "anachronisms".
On Mon, 29 Jun 2020 at 09:52, Andrey Semashev via Boost < boost@lists.boost.org> wrote:
On 2020-06-29 08:40, Vinnie Falco via Boost wrote:
On Sun, Jun 28, 2020 at 10:22 PM Schrom, Brian T via Boost <boost@lists.boost.org> wrote:
My suggestion is....
Yeah mailing lists are nice for the monotonically decreasing set of older engineers used to the anachronism but they are not in any way shape or form attractive for bringing in new, young blood.
Hopefully, the young blood will mature one day and realize the convenience of the "anachronisms".
The mailing list is highly inconvenient, definitely a thing that should be in the past. A forum would be awesome. A few quick reasons off the top of my head to use a forum: 1) Better quoting of previous posts (thereby killing the top posting issue). 2) Quotes from multiple posters can be addressed in a single reply. 3) No lengthy corporate signatures in every post. 4) Easy to see from a high level what all the topics of discussion are. At the moment there's a boost users list, a boost developers list. Think there's one for Spirit. Is there one for UBLAS too? Not sure what others. 5) Clients can subscribe to particular messages and get notifications of changes to those in their email (or when the return to the forum). This is better then scanning through an email inbox. 6) We all have different email clients. Every one of us needs to do configuration to mark the emails appropriately and move them to a particular folder. Boost emails are interspersed with my personal emails. Moving to a web-based forum will give us all our inboxes back. 7) Sometimes messages on the Boost list go to my email spam folders and therefore easily missed. This wouldn't happen anymore. 8) Ability to do polls (e.g. should a proposed library be included in Boost?). 9) Blocks of code will appear nicer assuming they're marked up. 10) Some email clients only allow threads up to x (e.g. 100) messages so you get a different line in your inbox although it's the same thread. 11) Threads can be closed. 12) Messages can be edited/refined after posting. 13) Better navigation through lengthy threads because pagination comes in to play. 14) Stickys available for FAQs. 15) Ability to put images in messages to show compilation time graphs, etc. Pete
On 2020-06-29 12:13, Peter Barker via Boost wrote:
The mailing list is highly inconvenient, definitely a thing that should be in the past. A forum would be awesome.
Not hoping to convert anyone, but still I'm going to answer a few points below so that it becomes more evident that most of these points are either solvable or not a problem.
A few quick reasons off the top of my head to use a forum:
1) Better quoting of previous posts (thereby killing the top posting issue).
All email clients, including the GMail web interface, have a decent quoting capability. Some clients (e.g. KMail) even color different levels of quotation differently. Top-posting is a cultural thing more than technical.
2) Quotes from multiple posters can be addressed in a single reply.
This is actually a bad thing to to do. When I'm looking though new messages in a topic, I often don't read each message though just to see if someone addressed or replied to me somewhere in the middle of his post. So, don't merge multiple replies into one post, please.
3) No lengthy corporate signatures in every post.
Using corporate email for mailing lists is probably not the best idea, unless you're participating on behalf of the company. However, signatures are configurable and removable when posting a message. I admit, this may be less convenient if you have to remove the signature before posting.
4) Easy to see from a high level what all the topics of discussion are. At the moment there's a boost users list, a boost developers list. Think there's one for Spirit. Is there one for UBLAS too? Not sure what others.
I believe, the suggestion was to have multiple forums, in which case you will have multiple lists of posts as well. If you mean grouping messages in threads then every decent email client has that capability.
5) Clients can subscribe to particular messages and get notifications of changes to those in their email (or when the return to the forum). This is better then scanning through an email inbox.
This is an advantage for casual one-time posters, I agree.
6) We all have different email clients. Every one of us needs to do configuration to mark the emails appropriately and move them to a particular folder. Boost emails are interspersed with my personal emails. Moving to a web-based forum will give us all our inboxes back.
Filtering is there for the rescue. I have 8 mailing lists in my mail, 5 of them are pretty active (dozens messages per day), each in its own folder. That is not counting notifications from various platforms, like GitHub and CIs, which are also nicely separated. All that took is to configure GMail filters once when I subscribed to a list or platform. I can't imagine how I could follow 8 different forums instead.
7) Sometimes messages on the Boost list go to my email spam folders and therefore easily missed. This wouldn't happen anymore.
Again, filters allow to mitigate this. GMail has "don't mark as spam" checkbox.
8) Ability to do polls (e.g. should a proposed library be included in Boost?).
It's not clear to me that polling should be integrated with the messaging system. And Boost reviews are not polls anyway. A review must not only contain accept/reject verdict. In fact, it may not contain one and only point out various points about the library. The review manager makes an informed decision about acceptance based on reviews, possibly in spite of the accept/reject verdicts in them.
9) Blocks of code will appear nicer assuming they're marked up.
To this I would agree, but only assuming a decent markup is available in the forum engine. In some forums I've seen the markup is terrible, to the point it is easier to just paste the code as is. And speaking of markup and formatting, some forums are too eager to interpret the text as a markup or various smileys, which is unacceptable for technical content. Plain text is the best media for technical communication.
10) Some email clients only allow threads up to x (e.g. 100) messages so you get a different line in your inbox although it's the same thread.
Nothing to say here, other than maybe try another client, or request a feature to remove the limit from the email client developers.
11) Threads can be closed.
Not a useful feature, IMHO. I don't remember a single time when I would want to explicitly close a discussion. Someone may have a reason to revive an old discussion, and there's nothing wrong with that.
12) Messages can be edited/refined after posting.
This one is debatable. On one hand, it is useful to be able to correct mistakes noticed just after posting. However, editing or rewriting posts after the discussion has moved on (i.e. after people have read and reacted to your original message) is not right.
13) Better navigation through lengthy threads because pagination comes in to play.
I hate pagination. I hate having to click through pages seeking for the one message I'm interested in or want to reply to. And I often do want to respond to someone in the middle of the discussion, as I get an idea some time after I read the post. This would be a major drawback for me. In the mail client I can skim through message headers looking for a particular date and author or use search without having to click through pages.
14) Stickys available for FAQs.
This might be useful.
15) Ability to put images in messages to show compilation time graphs, etc.
I don't think this is useful in a technical forum like Boost, more like a gimmick, but ok.
On 29/06/2020 22:30, Andrey Semashev wrote:
Using corporate email for mailing lists is probably not the best idea, unless you're participating on behalf of the company. However, signatures are configurable and removable when posting a message. I admit, this may be less convenient if you have to remove the signature before posting.
Actually, corporate signatures aren't always removable. Sometimes they're added by the mail server rather than the mail client.
4) Easy to see from a high level what all the topics of discussion are. At the moment there's a boost users list, a boost developers list. Think there's one for Spirit. Is there one for UBLAS too? Not sure what others.
I believe, the suggestion was to have multiple forums, in which case you will have multiple lists of posts as well.
If you mean grouping messages in threads then every decent email client has that capability.
Speaking as one of the anachronistic old engineers, I prefer using newsgroups (via gmane, creaky as it may be) over forums over mailing lists, in that order. Another group I frequently participated in recently retired a "real" newsgroup server and switched over to a mailing list, and I ended up not participating any further until after it was mirrored to gmane. (And I'm currently reading this list via gmane as well.) This isn't really any sort of philosophical issue; I just tend to forget that web forums exist, so don't check them as often, whereas both email and newsgroups are more in-your-face -- and I personally find the UX of newsgroups to be preferable. (Some people may regard "less in-your-face" as a feature, but I find it means more messages build up between checks which makes it take longer to catch up, increasing the likelihood of putting it off until you have "more time" and then quickly becoming unmanageable. Maybe that's just me.) But any change, no matter which direction, is likely to dislodge some people -- it's more a question of whether there'd be enough new people attracted to warrant it. (This happens with any kind of community.)
On Sun, Jun 28, 2020 at 9:24 AM Vinnie Falco via Boost < boost@lists.boost.org> wrote:
On Sat, Jun 27, 2020 at 4:36 PM Jeff Garland <azswdude@gmail.com> wrote:
Being in std:: really is the ultimate c++ distro.
Yes well this attitude needs to change as it is obviously unsustainable.
I guess it is obvious to some people but not others. But reality will impose itself on C++. People will treat the standard depending on what it actually is. If the committee continues the frantic innovation and release of untested stuff, it'll be treated like the immature product it actually is.
On Sat, Jun 27, 2020 at 6:12 PM Vinnie Falco via Boost <boost@lists.boost.org> wrote:
On Sat, Jun 27, 2020 at 3:46 PM Jeff Garland via Boost <boost@lists.boost.org> wrote:
Ideally what Zach proposes will ship under the Boost banner first. Why? So more than the maybe 20 people on the committee will look at it before the ink is dried and it ships with compilers.
It sounds like the committee's workflow is defective. If more people should interact with the library before it goes into the standard, here's a novel idea:
Don't put it in the standard yet.
That may be the right answer, but complaining about it won't fix it. The reality is that people are going to put stuff into the standard library. The question then is not whether or not they should, but what kinds of things go in. The answer ought to be well-tested existing practice. Living in Boost for a while gives us the most consistently good shot at that (you could just put stuff up on Github and still get a lot of users, but that happens less often). That's why I think we should promote the use of Boost as a viable path to a proposal.
Why does Boost.Text have to go into the standard right away? Why can't it enjoy life as its own non-std library for a few years, the way that Asio did? Plenty of users and companies can enjoy the Unicode library without it having to be in the std:: namespace.
It doesn't need to, for most definitions of "need". No one will die if it doesn't. No empires will fall. However, C and C++ are the only widely used production languages that do not have standard library support for Unicode text processing. I consider this embarrassing. The existence of a Boost version makes things better, to be sure. However, Boost is not ubiquitous, whereas the standard library is. Zach
On 6/27/20 3:46 PM, Jeff Garland via Boost wrote:
On Sat, Jun 27, 2020 at 9:02 AM Glen Fernandes via Boost < boost@lists.boost.org> wrote:
It used to not just be a bonus -- it's the prime reason Boost exists. If it no longer has that mission we should make that clearer.
It was the reason Boost was founded, but once C++ standard absorbed most of Boost foundational libraries, Boost needed a new purpose. There was much discussion of this around 2010ish but there wasn't much consensus, and we just continued without really thinking about it.
But Boost itself shouldn't compromise on quality - in its review process or what it ships in a Boost distribution, to serve any of those other interests.
The only reason boost was successful, and continues to be is that it's one of the few places where one can acquire quality quality C++ libraries including code, tests, documentation, rationale, etc. Vendor supplied C++ standard libraries also fulfill this role. But the C++ standard can't evolve fast enough and vendors couldn't keep up in any case. Hence the need for Boost.
That is a decision for the Boost community to make, while there is still a community.
That Boost must supply high quality software, and only such software, has been a fundamental premise of Boost since it's inception. The decision was made long ago. Of course the community could decide that quality could be de-emphasized in order to promote some other value(s) and that would be a decision for the community to make. But so far I don't recall anyone proposing that. If all C++ library development goes elsewhere then there won't
be much left.
Hmmm - I don't understand what that means. Is C++ library development going somewhere?
Putting a bunch of experimental libraries into a Boost release just because people have proposed them for standardization is not something we should do.
Hmmm - what does experimental mean in this context? If means that quality has been compromised to get the job finished, we shouldn't do it. If means some software which no one would ever think of putting into the standard (symbolic differentiation?), I wouldn't have any problem with it at all. If someone want's to strike out with a whole new direction for character encoding, I would OK with that. But what I would not be happy with is an incomplete/buggy/low quality of any of these things. People use boost because: a) it's documented b) it works c) it has passed a review process which certifies the above The above saves user time - which the fundamental thing that they care about.
I disagree. Consider how painful it is for a c++ programmer that wants to contribute to the review proposed libraries for the C++ standard. And by that I mean, go and use the implementation. In my case I was doing this for c++20 -- it was super painful. Aside from the time it took to go pull from different places, compiler support and library quality/robustness was all over the map.
How would Boost changing it's mission address this problem?
After sleeping on it I like the idea more than ever -- so maybe I'll work on it. And if Boost doesn't want to distribute it then it's more of the same mind share drain away from Boost. I think it would be fine to ship the proposed elements outside the main distro until it went thru a normal review. Ideally we'd get more authors to submit to a boost review and come under the tent. Maybe we could have some of the 'boostification' work done by Summer of Code students. Maybe this will led to more libraries like asio that can ship standalone and in Boost as well.
Note that the Boost Library Incubator (www.blincubator.com) was conceived to fulfill a role similar to that which you describe. The requirements to be accepted into the incubator are objective and require not subject review. The web site could/should be simplified/updated as much of the functionality is now better implemented within github itself. But in principle it seems similar to what you have in mind.
Understood, but we should care about his effort to standardize. Unicode is hard, it's a mess in C++, and average programmers could use a Boost (sorry, so sorry, not sorry :). Ideally what Zach proposes will ship under the Boost banner first. Why? So more than the maybe 20 people on the committee will look at it before the ink is dried and it ships with compilers.
All true, but it should be good enough to pass a boost review before the committee decides to consider it. Robert Ramey PS: Off topic TL;DR The role, goals, methods, of the C++ library committee have been the subject of much discussion of late. To many of us, it seems very clear that the process is not scaling and the committee as it currently operates can't keep up while still maintaining the level of quality that we and other users demand. Something is going to have to change here, but of course we can never agree. RR
Jeff
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Sat, Jun 27, 2020 at 9:20 PM Robert Ramey via Boost < boost@lists.boost.org> wrote:
On 6/27/20 3:46 PM, Jeff Garland via Boost wrote:
On Sat, Jun 27, 2020 at 9:02 AM Glen Fernandes via Boost < boost@lists.boost.org> wrote:
It used to not just be a bonus -- it's the prime reason Boost exists. If it no longer has that mission we should make that clearer.
It was the reason Boost was founded, but once C++ standard absorbed most of Boost foundational libraries, Boost needed a new purpose. There was
I must have missed something bc I never got the change of mission memo -- despite being at 'future of boost' in Aspen every year. Still, I mean it's pretty clear that the mission has adjusted over time. Part of the role became supporting std library equivalents on older versions of the standard. Part of it is offering useful extensions that aren't in the standard. Part of it is offering useful libraries that won't ever go into the standard. But the original mission stands. Before C++20 it was the case that a big part of the new content was still rolling in older Boost libraries (aka filesystem in 17). Networking still hasn't made it there - it is a 23 priority. Stacktrace might have a shot at 23 -- was close in 20, but ran out of time. Peter and Glen moved some shared_ptr facilities into 20. I'm helping to shepherd Process, because I believe that it should be there as well. So the pipeline isn't completely dead, but it's no longer the primary input.
That is a decision for the Boost community to make, while there is still a community.
That Boost must supply high quality software, and only such software, has been a fundamental premise of Boost since it's inception. The decision was made long ago. Of course the community could decide that quality could be de-emphasized in order to promote some other value(s) and that would be a decision for the community to make. But so far I don't recall anyone proposing that.
If all C++ library development goes elsewhere then there won't
be much left.
Hmmm - I don't understand what that means. Is C++ library development going somewhere?
Yes it has -- standalone repos on github. As it stands, boost has NO implementations of the c++20 major library changes (ranges, format, span, chrono). Maybe we will get jthread incorporated? How about synchronization primitives like barriers and semaphores? The container erase algorithms? Do we have scope_guard from the fundamentals TS that someone might propose to go 23 - no we don't. Will we have range library extensions already being evaluated for 23 -- seems unlikely, given that we don't have base ranges. So the part of the community that in the past has looked to Boost for 'bridge to a newer standard' is no longer being served going forward. And the part of the community looking at the future isn't being served either. Let me be clear that I'm not suggesting that we reduce quality and consistency. I'm just saying maybe we should think outside the box, like you were with the incubator, for encouraging the rapid incorporation of libraries proposed for the standard. Maybe there needs to be some concerted effort to make a case to library authors that it's worth their time to be part of Boost. Maybe the path doesn't 'start' with the standard review process. Maybe it's a Boost23 package that can be unpacked on top of the usual distro and has a set of boostified proposal libraries. If they go through the review then they would just go into the distro of course.
Putting a bunch of experimental libraries into a Boost release just
because people have proposed them for standardization is not something we should do.
Hmmm - what does experimental mean in this context? If means that quality has been compromised to get the job finished, we shouldn't do it. If means some software which no one would ever think of putting into the standard (symbolic differentiation?), I wouldn't have any problem with it at all. If someone want's to strike out with a whole new direction for character encoding, I would OK with that. But what I would not be happy with is an incomplete/buggy/low quality of any of these things.
People use boost because: a) it's documented b) it works c) it has passed a review process which certifies the above
The above saves user time - which the fundamental thing that they care about.
Let's consider the format library which went into c++20. It's substantial and useful work moving output past i/o streams. It's something that will impact most c++ developers. It's not in Boost, but in my view it would have been even better if it had been in Boost. There would have been more scrutiny of some aspects earlier in the process. The documentation would have been better because a boost review would have forced that to happen. And now there are extensions of that work being proposed -- but Boost isn't in the loop at all. Anyway, the 'implicit assumption' that the proposals and implementations are necessarily of low quality bc they are not in Boost is incorrect. But as mentioned elsewhere the standard deviation is higher -- the level of testing for most is clearly less bc they don't have 20 test runners on top of the standard github CI to test their code. Which means it may, or may not actually compile and work in my environment. Documentation is often a casualty as the effort is in preparation of materials for the committee and not for users.
contribute to the review proposed libraries for the C++ standard. And by that I mean, go and use the implementation. In my case I was doing this for c++20 -- it was super painful. Aside from the time it took to go
I disagree. Consider how painful it is for a c++ programmer that wants to pull
from different places, compiler support and library quality/robustness was all over the map.
How would Boost changing it's mission address this problem?
I see it more as getting back to the core mission, but adapting to the new realities.
After sleeping on it I like the idea more than ever -- so maybe I'll work on it. And if Boost doesn't want to distribute it then it's more of the same mind share drain away from Boost. I think it would be fine to ship the proposed elements outside the main distro until it went thru a normal review. Ideally we'd get more authors to submit to a boost review and come under the tent. Maybe we could have some of the 'boostification' work done by Summer of Code students. Maybe this will led to more libraries like asio that can ship standalone and in Boost as well.
Note that the Boost Library Incubator (www.blincubator.com) was conceived to fulfill a role similar to that which you describe. The requirements to be accepted into the incubator are objective and require not subject review. The web site could/should be simplified/updated as much of the functionality is now better implemented within github itself. But in principle it seems similar to what you have in mind.
Yeah, I agree there's a similarity. I think the difference is I'm thinking of an entire collection of libraries and not a single proposal.
Understood, but we should care about his effort to standardize. Unicode is hard, it's a mess in C++, and average programmers could use a Boost (sorry, so sorry, not sorry :). Ideally what Zach proposes will ship under the Boost banner first. Why? So more than the maybe 20 people on the committee will look at it before the ink is dried and it ships with compilers.
All true, but it should be good enough to pass a boost review before the committee decides to consider it.
The reality of the order is different -- the committee is already looking at it and that is informing the design. Robert Ramey
PS: Off topic
TL;DR
The role, goals, methods, of the C++ library committee have been the subject of much discussion of late. To many of us, it seems very clear that the process is not scaling and the committee as it currently operates can't keep up while still maintaining the level of quality that we and other users demand. Something is going to have to change here, but of course we can never agree.
Sure -- scaling is hard. And yeah, it's how the committee deals with that
is off topic for this list -- but it is clearly on committee members minds. On topic for this list is how WE, the boost community, deal with that scaling and velocity of the current process in the committee. Since at least one of the missions is to in fact help said committee ensure the highest quality library additions possible we might need some new approaches in the current context. Jeff
On Sun, Jun 28, 2020 at 10:43 AM Jeff Garland via Boost < boost@lists.boost.org> wrote:
On Sat, Jun 27, 2020 at 9:20 PM Robert Ramey via Boost < boost@lists.boost.org> wrote:
On 6/27/20 3:46 PM, Jeff Garland via Boost wrote:
On Sat, Jun 27, 2020 at 9:02 AM Glen Fernandes via Boost < boost@lists.boost.org> wrote:
It used to not just be a bonus -- it's the prime reason Boost exists. If it no longer has that mission we should make that clearer.
It was the reason Boost was founded, but once C++ standard absorbed most of Boost foundational libraries, Boost needed a new purpose. There was
I must have missed something bc I never got the change of mission memo -- despite being at 'future of boost' in Aspen every year.
Sorry to point this out.. But attending a face to face meeting is the least beneficial way to get an assessment as to what the Boost developer and user community state is. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net
On Sun, Jun 28, 2020 at 10:18 AM René Ferdinand Rivera Morell < grafikrobot@gmail.com> wrote:
On Sun, Jun 28, 2020 at 10:43 AM Jeff Garland via Boost < boost@lists.boost.org> wrote:
I must have missed something bc I never got the change of mission memo -- despite being at 'future of boost' in Aspen every year.
Sorry to point this out.. But attending a face to face meeting is the least beneficial way to get an assessment as to what the Boost developer and user community state is.
It's a data point. We have no scientific way to assess this unfortunately. Regardless, the mission didn't change for me, and from my imperfect sample some others as well. Maybe there's only 5 of us anachronisms left -- but it's more than zero. Jeff
On the subject of the mailing list: because one needs to be "on" it to participate, that makes it a better environment to conduct Boost reviews. Imagine doing that in front of a stackoverflow-type audience. I'm convinced that this would be contrary to the stated goal to keep the quality high. Perhaps we can benefit from the extra traffic, but that is a separate issue.
Gesendet: Montag, 29. Juni 2020 um 19:21 Uhr Von: "Emil Dotchevski via Boost" <boost@lists.boost.org> An: "Boost" <boost@lists.boost.org> Cc: "Emil Dotchevski" <emildotchevski@gmail.com> Betreff: Re: [boost] Boost, not LEWG
On the subject of the mailing list: because one needs to be "on" it to participate, that makes it a better environment to conduct Boost reviews. Imagine doing that in front of a stackoverflow-type audience. I'm convinced that this would be contrary to the stated goal to keep the quality high.
Why are people equating forums with SO? Contrary to forums, extended discussions are frowned upon on SO, and contrary to SO, forums usually don't rate posts (although some have a like button). SO is a site for Q&A, forums are centered around discussions. As someone who didn't grow up using mailing lists, I have to say I find them (and the archive) rather uncomfortable to use, so my guess is that this is to a large degree a matter of what you are used to and how much time you spend to setup your tools (kind of VI vs a gui text editor/IDE). Best Mike
On Tue, Jun 30, 2020 at 12:39 AM Mike via Boost <boost@lists.boost.org> wrote:
Why are people equating forums with SO?
That was my unfortunate mistake. I only used the comparison to highlight how the immediacy of visiting a website is different from having to register for a mailing list. Thanks
On 2020-06-30 12:42, Vinnie Falco via Boost wrote:
On Tue, Jun 30, 2020 at 12:39 AM Mike via Boost <boost@lists.boost.org> wrote:
Why are people equating forums with SO?
That was my unfortunate mistake. I only used the comparison to highlight how the immediacy of visiting a website is different from having to register for a mailing list.
You still have to register on StackOverflow.
On Tue, 30 Jun 2020 at 11:03, Andrey Semashev via Boost < boost@lists.boost.org> wrote:
On 2020-06-30 12:42, Vinnie Falco via Boost wrote:
On Tue, Jun 30, 2020 at 12:39 AM Mike via Boost <boost@lists.boost.org> wrote:
Why are people equating forums with SO?
That was my unfortunate mistake. I only used the comparison to highlight how the immediacy of visiting a website is different from having to register for a mailing list.
You still have to register on StackOverflow.
Only to post, upvote and comment, etc. You don't have to register if you want to visit and browse the questions and answers. If Boost moved to a forum it'd be analogous.
On 2020-06-30 18:30, Peter Barker via Boost wrote:
On Tue, 30 Jun 2020 at 11:03, Andrey Semashev via Boost < boost@lists.boost.org> wrote:
On 2020-06-30 12:42, Vinnie Falco via Boost wrote:
On Tue, Jun 30, 2020 at 12:39 AM Mike via Boost <boost@lists.boost.org> wrote:
Why are people equating forums with SO?
That was my unfortunate mistake. I only used the comparison to highlight how the immediacy of visiting a website is different from having to register for a mailing list.
You still have to register on StackOverflow.
Only to post, upvote and comment, etc. You don't have to register if you want to visit and browse the questions and answers. If Boost moved to a forum it'd be analogous.
You can browse mail list archive without registration.
On Tue, 30 Jun 2020 at 17:12, Andrey Semashev via Boost < boost@lists.boost.org> wrote:
On 2020-06-30 18:30, Peter Barker via Boost wrote:
On Tue, 30 Jun 2020 at 11:03, Andrey Semashev via Boost < boost@lists.boost.org> wrote:
On 2020-06-30 12:42, Vinnie Falco via Boost wrote:
On Tue, Jun 30, 2020 at 12:39 AM Mike via Boost <boost@lists.boost.org
wrote:
Why are people equating forums with SO?
That was my unfortunate mistake. I only used the comparison to highlight how the immediacy of visiting a website is different from having to register for a mailing list.
You still have to register on StackOverflow.
Only to post, upvote and comment, etc. You don't have to register if you want to visit and browse the questions and answers. If Boost moved to a forum it'd be analogous.
You can browse mail list archive without registration.
I was just correcting your statement about needing to register on StackOverflow.
On 2020-06-30 19:32, Peter Barker via Boost wrote:
On Tue, 30 Jun 2020 at 17:12, Andrey Semashev via Boost < boost@lists.boost.org> wrote:
On 2020-06-30 18:30, Peter Barker via Boost wrote:
On Tue, 30 Jun 2020 at 11:03, Andrey Semashev via Boost < boost@lists.boost.org> wrote:
On 2020-06-30 12:42, Vinnie Falco via Boost wrote:
On Tue, Jun 30, 2020 at 12:39 AM Mike via Boost <boost@lists.boost.org
wrote:
Why are people equating forums with SO?
That was my unfortunate mistake. I only used the comparison to highlight how the immediacy of visiting a website is different from having to register for a mailing list.
You still have to register on StackOverflow.
Only to post, upvote and comment, etc. You don't have to register if you want to visit and browse the questions and answers. If Boost moved to a forum it'd be analogous.
You can browse mail list archive without registration.
I was just correcting your statement about needing to register on StackOverflow.
And I was pointing out that there is no difference between StackOverflow and mailing list in terms of immediacy of access.
So I'm going to chime in here, in aggregate. I will try to focus on answering the question of "What is Boost Good For?" from the perspective of a user, and as a user having participated in reviews. It's a large brain dump, so there's probably typos and other bad things. [[ Boost and the Ecosystem ]] In my opinion, Boost is not dead (no great software library is), but it has waned in usefulness substantially. You don't even have to take my word for it, Boost authors already did some basic sleuthing about it: https://www.reddit.com/r/cpp/comments/gfr46l/why_you_trust_in_boost/ https://www.reddit.com/r/cpp/comments/gfowpq/why_you_dont_use_boost/ You'll note that the "don't use boost" had many more comments and upvotes, whereas the "trust in boost" had many less comments and upvotes. Reading both confirms some of my own biases, which is that Boost, as an ecosystem, does not offer a lot of bang for its buck because it exists in a space where it competes with the Standard Library, and does not complement it. This creates an interesting problem. I could use Boost.Container's vector, but what benefit does it offer me over std::vector, except that it has more predictable performance characteristics in now-10-year-old STLs? (It's not better than the current STL; I measured.) I could use Boost's type traits, or I could require C++11, work around GCC4.8 being a nightmare, and no longer have that source dependency. I could use things from Boost.Core, but I could also just move to C++11/14 and obsolete many of its usages. And so on, and so forth. Opting into the boost ecosystem is expensive, insofar that it's a really bad trade for interop. I can't talk to external libraries with Boost's vector, or its unordered map, optional (even if the Standard's is strictly worse in every way), variant, etc.. Interoperability matters, which means boost usage in "middleware" libraries -- at least on its edges and boundaries -- drops off a cliff. Boost is not "the glue that holds a really shitty C++ universe together" (C++03 and before), it becomes "the thing that costs me maintenance hours and I have to spend extra time supporting in my abstractions" (C++11 and above). Another point: note that Meeting C++'s survey about regular expression showed that an OBSCENE number of people used std::regex, despite it being the literal worst part of every std:: implementation (aside from wstring_convert), with the reason "because it is there". You need to make an EXTREMELY compelling sell to get more people to pick up your library, and if the majority of your libraries are "compete with the standard", you will lose even if the performance of the Standard is actual dog poo. Speaking of performance... [[ Boost and Performance ]] Further hurting Boost's proposition in the ecosystem is its performance characteristics and its inability to capitalize on decades-old ideas. My computer is still shot so I cannot yield the benchmarks and everything, but finding out that I could read 2 Boost Author's std papers on allocations and other tricks (Howard Hinnant, Ion Gaztanaga) and find that neither of the tangible performance gains they described were implemented in Boost's Allocators or Containers means I had absolutely no compelling reason to pick Boost over the Standard for the thing I was rolling (in this case, my own std::vector or other containers). Boost -- for its basic abstractions -- do not provide compelling improvements over the status quo for fundamental things for me to care enough about Boost alternatives to core things to begin with. (This changes with things like Peter Dimov's boost::variant2, which offer tradeoffs I as an application developer are deeply interested in for many domains, and thus pays off). This speaks to the ways Boost is used now: for very specific use cases not covered by the standard, and very specific performance metrics the standard never will meet. [[ Boost and Tradeoffs ]] Unless I pick a very specific library (StaticString, SML, variant2, Log, String Algorithms, ASIO, Beast, etc.) that offers me a very tangible gain in "yes, absolutely, this accelerates my development and has acceptable performance characteristics", Boost's general core is not worth it. It's monolithic nature makes it hard to opt into many of its smaller libraries "just because". Distribution is often an extreme pain in the ass. Build system gripes are ripe in the reddit threads, and there's been at least 3 (!!) official, they-recorded-this-for-1+-hours-and-practiced-this-for-many-more-hours talks about getting Boost to different build systems and modularizing boost. If that isn't enough of an indication that Boost's method of distribution maybe needs to be looked at more closely, I honestly don't know how to explain the need better! Before, that monolith was great: the Standard was, quite frankly, hot steaming garbage so Boost's core made all that go away and provided stability amongst the insanity of many compilers. That is not the case anymore, and accepting the costs of the monolith in exchange for only a handful of libraries is often a far worse trade, especially if that library does not come with distinct gains. This is why people keep asking for "Boost, but based on a higher standard"; this is not just because "unga bunga cruft bad", it's because they want to see /more/ useful libraries that pushed the boundaries of C++ farther out than ever before, just like Boost did in the 2000's. [[ Boost and The People's Needs ]] As I stated before, people's needs have shifted. C++ is not The Badlands anymore, and even MSVC is coming out to play nice. Boost is having a problem addressing the needs people have, today, which are sometimes extremely niche. This is why I am partly disappointed by the result of the Text Review. As I stated in my review, Text in C++ sucks. Boost does not do better than the Standard, save for some string algorithms and some basic Locale "improvements". This was a chance, even if not perfect, to provide a library that really made Boost stand out as "has something the Standard can only dream of". boost::text's "text" container -- as the kids would say -- slapped. Grapheme cluster iterators, utf8 storage, insertion and removal based on what most people perceive as characters handled transparently for me?? That's the wet dream of text management. Coupled with a Stepanov reimagining of Standard Unicode algorithms that were just a straight translation of the pointer-based, weird ICU interfaces, absolutely. Yes, not having allocators was terrible and not having the ability to choose underlying encoding sucked, but it got *most* people a good chunk of the way. There was room for going backwards and filling out the problems in v2. Not having the library -- and encouraging the text layer not to come back as part of the next resubmission of the library -- is a huge blow to "this really addresses one of the serious contemporary C++ problems". Maybe Zach will resubmit that layer, but we missed out on the sweet spot of addressing a need that neither Standard C++ nor most shops handle nicely. I do hope the library comes back! This also speaks to LEWG. In all frankness, if Boost's purpose is to be invalidated by the Standard every 3 or 6 years, why waste the time submitting to Boost when Boost is just "standard, but outside and sometimes before the standard"? If your goal becomes "Lots of C++11 that fill the gaps", well then duh nobody's going to submit new stuff to Boost because you've made it explicitly clear your job is being a polyfill for old libraries, not providing new, cutting edge libraries like 20-years-ago Boost was. [[ In Conclusion ]] Boost is successful. Not was: is. But its original space has been consumed by the standard, and if we want to enjoy a "Boost Renaissance", we need to address people's needs and meet them where they are, rather than keep trying to pull them into a way of Boost that is, quite frankly, no longer necessary in many ways. Higher standards. Libraries that provide good tradeoffs. Libraries that address the needs that are going out in front of people today, not the needs 10 or 15 years ago. Boost may need to actually reach out to people and very much handhold them through the process of library submission, review, and improvement to convince a few key cases that Boost is still extremely relevant to modern needs. Maybe that will bring in even more folk; encourage them to submit here, once they see that Boost libraries are once more the place to go to solve real problems, with a tangible feedback loop. Right now it's hard to gauge the effect of a Boost library, since Boost is doing very little to distinguish itself from the Standard (again, why go through Boost if you can do GitHub + LEWGI + LEWG + LWG instead?). Boost should be the cutting edge again. This does not mean the quality has to go down: but there should be active encouragement of exploration of new topics OR addressing people's needs. Boost.Text, Boost.Unicode, maybe even Boost.Audio, and more... [[ Mailing Lists and Tools In General ]] Mailing lists are fine for power users. And yes, I really mean power users! This could be my young buck inexperience showing, but there is a real problem with having to manage a lot of these things yourself. While people can configure amazing awesome mail clients capable of great feats, most of us don't have anything like that. Some small examples: - I had no idea what "top posting" was until someone informed me that (by default) g-mail's reply feature was automatically top posting. There is, of course, no way to change this in the options, but it is still against Boost etiquette to do so. So now I need to manually relocate the start of my post, and I have to do this every time I start an e-mail. - Tracking threads is hilarious in an e-mail client. This single post has ended up in 3-4 different threads, sometimes because some people's mailing client clears out response IDs and other times because it was a deliberate fork. I have no idea, and now I have to track the 4 threads to this, often without any context of where this thing came from even if I scroll up *this* thread in particular. - Formatting. Boost's mailing list is nice enough to accept my HTML e-mails, but I have no assurance my e-mails are <b>NOT</b> showing up <i>strangely</i> for everyone now with weird things (so I have to default to plain text and, essentially, make up some form of /markup/ in my head or use what I've observed about the mailing list). Consistent formatting (e.g., "everyone uses markdown and that's what renders") brokers a common ground between mailing list users for code formatting, emphasis, and general text decorum / presentation. Basically, mailing lists are wild-wild wests of formatting and quality. A platform that got rid of that etiquette and just let me conform to an established format (GitHub Issues, etc.) greatly lowers the barrier to being able to speak up. On Tue, Jun 30, 2020 at 12:41 PM Andrey Semashev via Boost <boost@lists.boost.org> wrote:
On 2020-06-30 19:32, Peter Barker via Boost wrote:
On Tue, 30 Jun 2020 at 17:12, Andrey Semashev via Boost < boost@lists.boost.org> wrote:
On 2020-06-30 18:30, Peter Barker via Boost wrote:
On Tue, 30 Jun 2020 at 11:03, Andrey Semashev via Boost < boost@lists.boost.org> wrote:
On 2020-06-30 12:42, Vinnie Falco via Boost wrote:
On Tue, Jun 30, 2020 at 12:39 AM Mike via Boost <boost@lists.boost.org
wrote:
> Why are people equating forums with SO?
That was my unfortunate mistake. I only used the comparison to highlight how the immediacy of visiting a website is different from having to register for a mailing list.
You still have to register on StackOverflow.
Only to post, upvote and comment, etc. You don't have to register if you want to visit and browse the questions and answers. If Boost moved to a forum it'd be analogous.
You can browse mail list archive without registration.
I was just correcting your statement about needing to register on StackOverflow.
And I was pointing out that there is no difference between StackOverflow and mailing list in terms of immediacy of access.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 01/07/2020 05:44, JeanHeyd Meneide via Boost wrote:
So I'm going to chime in here, in aggregate. I will try to focus on answering the question of "What is Boost Good For?" from the perspective of a user, and as a user having participated in reviews. It's a large brain dump, so there's probably typos and other bad things.
Firstly, this is a great reply. Erudite, useful, positive, actions-based. Anybody who hasn't read all of it ought to. What is especially noticeable is the focus on the end user experience rather than constant giving out about other people and orgs not doing things right in some Boost people's opinion.
Not having the library -- and encouraging the text layer not to come back as part of the next resubmission of the library -- is a huge blow to "this really addresses one of the serious contemporary C++ problems". Maybe Zach will resubmit that layer, but we missed out on the sweet spot of addressing a need that neither Standard C++ nor most shops handle nicely. I do hope the library comes back!
I could not agree more with this point! Whilst yes, Unicode is the pain point in the ecosystem, and yes, more standards targeted libraries ought to go through Boost before LEWG, and yes, the most efficient use of Zach's limited spare time is to concentrate on what is (relatively speaking) easiest, it is actually replacing **std::string** which is the golden calf needing slaughtering here. I wouldn't wish achieving that on my worst enemy. It would be awful. But it would also come with outsize improvements across the ecosystem in all sorts of non-obvious ways. Like Outcome had. Improving strings and text in C++ would be incredibly hard, but if successful, incredibly beneficial.
Boost may need to actually reach out to people and very much handhold them through the process of library submission, review, and improvement to convince a few key cases that Boost is still extremely relevant to modern needs. Maybe that will bring in even more folk; encourage them to submit here, once they see that Boost libraries are once more the place to go to solve real problems, with a tangible feedback loop. Right now it's hard to gauge the effect of a Boost library, since Boost is doing very little to distinguish itself from the Standard (again, why go through Boost if you can do GitHub + LEWGI + LEWG + LWG instead?). Boost should be the cutting edge again. This does not mean the quality has to go down: but there should be active encouragement of exploration of new topics OR addressing people's needs. Boost.Text, Boost.Unicode, maybe even Boost.Audio, and more...
I don't personally think that would work. The cost benefit to getting into Boost just isn't there. I did it once. I'll never do it again. What I do think would work is if Boost v2 becomes a peer anointed collection of Boost-endorsed third party libraries bundled into a distribution i.e. getting into Boost means that your library ships with every Linux and Windows distro thenceforth, a common distribution channel. This means that "getting into Boost" shifts from the author doing the driving into the Boost community choosing a set of rules by which popular C++ libraries are selected for candidacy (e.g. >= 5 years maintained, permissive licence, STL naming conventions, widely portable etc), and then persuading the author to undertake any changes which a peer review decides upon. That effectively turns Boost into a highly selective package manager. I find that just fine. (Note that current Boost v1 ought to remain as-is, package-manager Boost would be a separate v2)
Basically, mailing lists are wild-wild wests of formatting and quality. A platform that got rid of that etiquette and just let me conform to an established format (GitHub Issues, etc.) greatly lowers the barrier to being able to speak up.
I find the mailing list stuff greatly overdone. "Young people" have no problem with mailing lists if there is a motivation to join. Back when I was applying myself at Boost, we had a constant incoming stream of new blood, because I was going out there and setting up a pipeline to bring young people into Boost. Some even tried their hand at getting a library into Boost. Only one succeeded, but all of them figured out mailing lists just fine, and they joining up here caused other young people to also sign up. But since I moved on, that pipeline has dried up, so mailing list traffic has dropped, vitality has ebbed etc etc. Participation and relevance doesn't "just happen". It occurs when an investment in making it happen occurs over many years. WG21 grows every year because there is a bunch of people investing in making it grow every year. Boost has not grown every year recently because the people who were investing in its growth a few years ago have moved on, so right now there is a lull. I'd like to hope that instead of complaining about others over which Boost folk have no control and indeed just look bitter by the constant complaining, some here might consider stepping up and investing effort outside the ivory tower, create vitality, restore relevance, by *engaging* with the ecosystem and its current needs instead of complaining about it. Niall
participants (16)
-
Andrey Semashev -
Emil Dotchevski -
Gavin Lambert -
Glen Fernandes -
JeanHeyd Meneide -
Jeff Garland -
Mike -
Niall Douglas -
Peter Barker -
Peter Dimov -
René Ferdinand Rivera Morell -
Robert Ramey -
Schrom, Brian T -
Ville Voutilainen -
Vinnie Falco -
Zach Laine