Re: [boost] [modularization] proposal and poll
I'll top post my reply as Robert's valuable post didn't make it onto the list again. Please do read his reply below, it's worth reading as Robert is one of the lead thinkers on the steering committee about this. Robert, I think you are under a misapprehension about what I mean by "fork". By a fork, I mean forking just a very small part of existing Boost, namely whatever minimal support is necessary to start from scratch with a new *empty* set of C++ 14 only Boost libraries. I don't propose to port *any* of the legacy Boost libraries whatsoever, they stay where there are. If their maintainers - or a sponsor - are willing to do: 1. Make their library entirely C++ 11/14 STL based, porting only the absolute minimum of old Boost. 2. C++ Modules ready i.e. restructured and reorganised to properly fit C++ Modules. 3. Contribute any general utility code to the core utilities library, not duplicating any functionality there, and in a form suitable for entering the C++ 17 STL. 4. Meet the raised unit test and CI soak test and sanitiser/valgrind requirements. Then they have a good chance of their library appearing highly ranked in the list of C++ 14 Boost libraries, where that ranking is generated by a set of clang AST analysers. Does this make sense? I am specifically advocating a structural break, a clean start. I think working on a fresh, empty Boost will get people to volunteer to give up family time to write Boost code again. Right now with the present situation there are few incentives to sacrifice family time. That needs to change for Boost to survive, else the continuing slow decline will continue. Niall On 29 May 2014 at 17:52, Robert Ramey wrote:
On Thursday, May 29, 2014 2:17:11 PM UTC-7, Niall Douglas wrote:
On 29 May 2014 at 22:22, Julian Gonggrijp wrote:
If a fork of Boost becomes necessary later this year,
LOL - this is not going to be necessary.
The hard part isn't what to do.
LOL - not for you!
The hard part is gaining community buy in when "their" code gets broken by the necessary changes. I have concluded it isn't possible,
LOL - you've underestimated the amount of work to convert everything to C++11 by a factor of .... 1000 ? Basically it's a whole rewrite of 100 modules. And the gain is ....?
hence me proposing a fork where such
"radical" changes won't upset anyone.
Your free to do this. And you should if you really believe that it would benefit anyone or anything.
I think it may be easier for the steering committee to justify any
decision on this proposal,
The steering committee doesn't have anything to decide here. The "Proposal" is:
1. Reduction of dependencies between Boost libraries.
It's not clear what action is being proposed - but I'm pretty sure the steering committee won't be doing it.
2. Simple but effective automation of dependency handling.
I'm pretty sure the steering committee won't be doing this either. If anyone believes that they can implement "simple and effective" automation of dependency handling - just go ahead and do it and let us see it.
Decisive and immediate action on this is vital if Boost is to survive. I vote yes to both, ASAP.
LOL - There is wide agreement that boost has growing pains and will have to evolve. But I haven't seen any proposals for "Decisive and Immediate" which would do anything but make things worse.
And since you've got me started - Here is what boost needs go to the next step.
a) Make the review process more effective and efficient - we're taking real practical action to address this now. The jury is still out regarding the effectiveness of our efforts - but we ARE actually doing something.
b) Recognize that we now have 4 variants of C++ - C++98, C++03, C++11 and C++14. Our infrastructure doesn't explicitly address this. The following needs to change 1) for each library we need to explicitly state somewhere what version(s) of C++ the library is meant to support. 2) support running of tests and builds for only those platforms.
I've suggested that we enhance B2 to address this. So far no one has responded to this suggestion
Note that this would have he effect of encouraging libraries to evolve to later versions of C++ with minimal disruption to both library authors and users.
c) Decouple Deployment of Boost Libraries from the Certification of boost libraries. Beman has noted that what he would like to see is something like CYGWIN whereby one specifies what one want's and somehow automagically you get that plush what you need. I realize that this is more or less what is being suggested here. But no one has presented credible proposal for making it it happen.
This would also address the issue of "old" libraries. As they fall into disuse are become superseded by newer ones, the can still be in boost even though their frequency of deployment drops off.
The above constitutes a real path forward. This is what Boost needs for the next 15 years.
Robert Ramey
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Does this make sense? I am specifically advocating a structural break, a clean start. I think working on a fresh, empty Boost will get people to volunteer to give up family time to write Boost code again.
All I see from this idea is a requirement to spend even more time on Boost. Just my 2c yours, John.
On 30 May 2014 at 12:04, John Maddock wrote:
Does this make sense? I am specifically advocating a structural break, a clean start. I think working on a fresh, empty Boost will get people to volunteer to give up family time to write Boost code again.
All I see from this idea is a requirement to spend even more time on Boost. Just my 2c yours, John.
It should be fun again to work across Boost instead of within silos John. So why do I keep saying end of this year? 1. I need to try removing Boost as a dependency from all my own code first to figure out what really is the minimum needed. I'm blocked on expected<> for this right now, I need that to eliminate the need for Boost.Thread. 2. I need a meta test framework which lets you whatever underlying test framework. This lets me swap out Boost.Test for any other test framework, I really don't care which so long as it outputs Jenkins CI results. 3. Keep building out my CI based quality assessment framework for the wider AFIO project, for which I need at least to write: a. A clang AST parser which warns on things like move constructors without noexcept and other things I keep forgetting in my code etc. b. A clang source rewriter which does a live Boost to STL source conversion. This will mirror the minimum of Boost I need into a C++ 14 edition, per commit to original Boost. 4. I'm thinking of all this as being a great showcase for my proposed graph database. See my C++ Now presentation on what I proposed as a future "as if all header only" C++ build system. I'm basically writing all this for my own purposes, but if others find it useful, they can hop onboard. I hope to restart work on all this after June 15th, health permitting. It's been a very long hiatus these last many months sadly. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On Fri, May 30, 2014 at 5:03 AM, Niall Douglas
Robert, I think you are under a misapprehension about what I mean by "fork". By a fork, I mean forking just a very small part of existing Boost, namely whatever minimal support is necessary to start from scratch with a new *empty* set of C++ 14 only Boost libraries.
I don't propose to port *any* of the legacy Boost libraries whatsoever, they stay where there are.
This doesn't sound like a fork at all. Why not just call it something different? Then there would be a place for modern development without having to disambiguate what boost v1 means vs. boost v2? This would free up some of the tension in the community around supporting legacy toolsets vs. diving into the new. Just my $0.02. Tom Kent
Niall Douglas wrote:
Robert, I think you are under a misapprehension about what I mean by "fork". By a fork, I mean forking just a very small part of existing Boost, namely whatever minimal support is necessary to start from scratch with a new *empty* set of C++ 14 only Boost libraries.
To be honest I think Robert is right that forking is not necessary, even if it is a small subset of all libraries, and in particular I'm a bit sceptical that starting from scratch in any way would be a good idea. Evolutionary changes, of the type that I propose and of the type that Robert proposes, seem much more productive to me.
I don't propose to port *any* of the legacy Boost libraries whatsoever, they stay where there are. If their maintainers - or a sponsor - are willing to do:
1. Make their library entirely C++ 11/14 STL based, porting only the absolute minimum of old Boost.
2. C++ Modules ready i.e. restructured and reorganised to properly fit C++ Modules.
3. Contribute any general utility code to the core utilities library, not duplicating any functionality there, and in a form suitable for entering the C++ 17 STL.
4. Meet the raised unit test and CI soak test and sanitiser/valgrind requirements.
While such changes might have value, they take much more work in a much more intrusive way than the more evolutionary type of proposal. I think Robert would be right to expect that few library maintainers will be willing to participate in such work.
Then they have a good chance of their library appearing highly ranked in the list of C++ 14 Boost libraries, where that ranking is generated by a set of clang AST analysers.
Does this make sense? I am specifically advocating a structural break, a clean start. I think working on a fresh, empty Boost will get people to volunteer to give up family time to write Boost code again. Right now with the present situation there are few incentives to sacrifice family time. That needs to change for Boost to survive, else the continuing slow decline will continue.
I don't think Boost is dying. I think with time, the changes you propose will happen anyway (except for the fork), one library at a time.
Niall
On 29 May 2014 at 17:52, Robert Ramey wrote:
I think it may be easier for the steering committee to justify any decision on this proposal,
The steering committee doesn't have anything to decide here. The "Proposal" is:
1. Reduction of dependencies between Boost libraries.
It's not clear what action is being proposed - but I'm pretty sure the steering committee won't be doing it.
For clarity, I was not proposing that the steering committee would do the work. Rather, I was proposing that the steering committee would endorse the work (i.e., make it an official plan) so that dependency reduction will be considered a joint goal of all library maintainers as well as anyone willing to do pull requests. Stephen Kelly would take an advisory role in this project, which includes doing suggestions for changes.
2. Simple but effective automation of dependency handling.
I'm pretty sure the steering committee won't be doing this either. If anyone believes that they can implement "simple and effective" automation of dependency handling - just go ahead and do it and let us see it.
I have said I'm willing to do this. I'm not doing it *yet* simply because (1) I don't currently have the time (but I do want to create time for it) and (2) I believe it will be more worthwhile if most libraries do not depend on half of Boost.
Decisive and immediate action on this is vital if Boost is to survive. I vote yes to both, ASAP.
LOL - There is wide agreement that boost has growing pains and will have to evolve. But I haven't seen any proposals for "Decisive and Immediate" which would do anything but make things worse.
Please explain to me and the rest of the list how what I proposed would make things worse.
And since you've got me started - Here is what boost needs go to the next step.
a) Make the review process more effective and efficient - we're taking real practical action to address this now. The jury is still out regarding the effectiveness of our efforts - but we ARE actually doing something.
b) Recognize that we now have 4 variants of C++ - C++98, C++03, C++11 and C++14. Our infrastructure doesn't explicitly address this. The following needs to change 1) for each library we need to explicitly state somewhere what version(s) of C++ the library is meant to support. 2) support running of tests and builds for only those platforms.
I've suggested that we enhance B2 to address this. So far no one has responded to this suggestion
I have been on a Boost hiatus between December and May, so that may explain why I missed your suggestion. I highly approve of it. By the way, since you are keen to take into account the "who": did your suggestion address who should execute the idea?
Note that this would have he effect of encouraging libraries to evolve to later versions of C++ with minimal disruption to both library authors and users.
c) Decouple Deployment of Boost Libraries from the Certification of boost libraries. Beman has noted that what he would like to see is something like CYGWIN whereby one specifies what one want's and somehow automagically you get that plush what you need. I realize that this is more or less what is being suggested here. But no one has presented credible proposal for making it it happen.
Maybe I can convince you if I implement the scripts that I have in mind.
This would also address the issue of "old" libraries. As they fall into disuse are become superseded by newer ones, the can still be in boost even though their frequency of deployment drops off.
The above constitutes a real path forward. This is what Boost needs for the next 15 years.
Robert Ramey
participants (4)
-
John Maddock -
Julian Gonggrijp -
Niall Douglas -
Tom Kent