What I would like to see is more encouragement for the idea of boost evolution. But I have well defined ideas about how that should occur. I articulated these ideas is quite a bit of detail at C++Now in 2015 to a packed house. It wasn't recorded so you'll have to take my word for it. All is not lost though. For those who might be interested I kept my practice recordings for the narrative on the slides and attached them to each slide. So you can get a good feeling for the presentation by checking out http://www.blincubator.com/C++Now2015/index.html If you do this don't forget to checkout the last two slides (including the audio)! in real life it was much better!!! When I articulated my particular suggestions at the conference there was a lot of push back and I sort of lost control of things. On the other hand, there was a lot of enthusiasm for my "call to action". I didn't expect any drastic changes. But as I look back a year I do see some real progress. I see: a) more and better reviews b) more interest, discussion and criticism of documentation c) 30 libraries in the incubator. Some have already been added to boost. d) Now movement on opening up the build/test system to evolution. e) A program in place to make more resources available for maintaining existing libraries. The complains of unmaintained libraries have diminished by quite a bit - I don't know for a fact that this is related to this program - maybe it's just a happy coincidence. A couple of things have made much progress. a) modular deployment and dependency management. No surprise here as this is a job of major, major difficulty. b) policy for library deprecation - not really hard but really very low priority. c) improvements in incubator - no real progress - but it's probably as good as it needs to be. d) boost website improvement - no discernible progress. There is one big lesson from all this: a) Boost is not a company - we don't take direction from the top. b) Boost is not a government - we actually do something. c) Boost is a religion - want something changed, start preaching. Get other people on board. Convince people people to start doing something. Take a look at the CMake history. There was a huge effort undertaken from the top to switch to CMake for build / test. It was a failure because it tried to do it from the top down. I'm thinking that the promoters of this idea concluded that the problem wasn't ambitious enough and added deployment to the task and built rypll. This had as key collaborators our most capable and hard core developers - including David Abrahams and Eric Neibler. Huge amount of expended effort but not much came out of it. I think if you want to help boost evolve - remember Boost is a religion. We are the jesuits of C++. Bjarn's marines - the tip of the spear. We ambush the world with a new idea which builds or replaces something else. We do it in an insidious manner. The opening up to CMake has proceeded steadily over years until it's a the cusp of victory. No one saw it coming and here it is. The world doesn't change from great initiatives, it changes when the old order collapses while espending it's existence to deny change. I've been told on this is a right wing world view - and so it is - oh well. So I encourage those who want to contribute to Boost and by extension C++ to consider using this approach. I think you'll be more successful. Robert Ramey
On Tue, May 17, 2016 at 10:37 AM, Robert Ramey <ramey@rrsd.com> wrote:
Take a look at the CMake history. There was a huge effort undertaken from the top to switch to CMake for build / test. It was a failure because it tried to do it from the top down. I'm thinking that the promoters of this idea concluded that the problem wasn't ambitious enough and added deployment to the task and built rypll. This had as key collaborators our most capable and hard core developers - including David Abrahams and Eric Neibler. Huge amount of expended effort but not much came out of it.
This is a false account of what happened. CMake was dropped because the modularization to git was considered a worthwhile thing to do first. After the so-called top-down transition to git (which was good for C++, but bad for insiders), the steering committee somehow came to the conclusion that their job wasn't to steer. After last week's future of boost session (or lack-of rather), my understanding is that this is being revisited. Boost cannot evolve the way it has in the past. When it was getting started, we didn't have over-representation of groups who benefit from the status-quo. We didn't have the idea of servicing the "Boost community" instead of the "C++ community". Either the steering committee will step up to protect the original vision of Boost, or the vision of Boost will change to serve the insiders. This means life or death for boost and, frankly, it's been dying over the past few years. Help me Obi Wan Kanobi you're my only hope. -- David Sankel
David Sankel wrote:
Boost cannot evolve the way it has in the past. When it was getting started, we didn't have over-representation of groups who benefit from the status-quo. We didn't have the idea of servicing the "Boost community" instead of the "C++ community".
I honestly have no idea what you're talking about. What is this hypothetical "Boost community" that is supposedly being served? What are those over-represented groups? Are you referencing something with which I am not familiar?
On 17 May 2016 at 20:59, Peter Dimov wrote:
David Sankel wrote:
Boost cannot evolve the way it has in the past. When it was getting started, we didn't have over-representation of groups who benefit from the status-quo. We didn't have the idea of servicing the "Boost community" instead of the "C++ community".
I honestly have no idea what you're talking about. What is this hypothetical "Boost community" that is supposedly being served? What are those over-represented groups? Are you referencing something with which I am not familiar?
This reply surprises me. A *lot* of people have been expressing this sentiment during the past four years, myself and Stephan Kelly pop to mind in particular. A thread not too long ago entitled "Boost is dead" or something like that was a *very* long running thread. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Niall Douglas wrote:
On 17 May 2016 at 20:59, Peter Dimov wrote:
David Sankel wrote:
Boost cannot evolve the way it has in the past. When it was getting started, we didn't have over-representation of groups who benefit from the status-quo. We didn't have the idea of servicing the "Boost community" instead of the "C++ community".
I honestly have no idea what you're talking about. What is this hypothetical "Boost community" that is supposedly being served? What are those over-represented groups? Are you referencing something with which I am not familiar?
This reply surprises me. A *lot* of people have been expressing this sentiment during the past four years, myself and Stephan Kelly pop to mind in particular. A thread not too long ago entitled "Boost is dead" or something like that was a *very* long running thread.
I notice that among all that sentiment expression you forgot to answer my questions.
David, On 17/05/2016 20:27, David Sankel wrote:
On Tue, May 17, 2016 at 10:37 AM, Robert Ramey <ramey@rrsd.com> wrote:
Take a look at the CMake history. There was a huge effort undertaken from the top to switch to CMake for build / test. It was a failure because it tried to do it from the top down. I'm thinking that the promoters of this idea concluded that the problem wasn't ambitious enough and added deployment to the task and built rypll. This had as key collaborators our most capable and hard core developers - including David Abrahams and Eric Neibler. Huge amount of expended effort but not much came out of it.
This is a false account of what happened. CMake was dropped because the modularization to git was considered a worthwhile thing to do first. After the so-called top-down transition to git (which was good for C++, but bad for insiders), the steering committee somehow came to the conclusion that their job wasn't to steer. After last week's future of boost session (or lack-of rather), my understanding is that this is being revisited.
Could you clarify why you think your account is true, and Robert's is false? I don't know what's happening at C++ Now, but I don't think you regularly participate in this mailing list, whereas Robert does, so I'm surprised by the forceful statements that you make.
Boost cannot evolve the way it has in the past. When it was getting started, we didn't have over-representation of groups who benefit from the status-quo. We didn't have the idea of servicing the "Boost community" instead of the "C++ community". Either the steering committee will step up to protect the original vision of Boost, or the vision of Boost will change to serve the insiders. This means life or death for boost and, frankly, it's been dying over the past few years.
Just as reminder, the original vision of Boost can be found at http://boost.org, and it cannot be protected in its entirety for long - the C++ standard is not infinite, and the role of Boost as "existing practice" for standardization becomes less relevant as the standard becomes longer, while its role as collection of peer-reviewed production libraries will probably be more important. I don't know who are insiders that are getting served, and what benefits who gets, and what "C++ community" you have in mind, but anybody I discuss Boost with are mostly concerned about overuse of templates and meta-programming, along with the lack of any API or ABI stability. Serving those C++ users requires stability and solid engineering above all, and this is what is presently missing. -- Vladimir Prus http://vladimirprus.com
I don't know who are insiders that are getting served, and what benefits who gets, and what "C++ community" you have in mind, but anybody I discuss Boost with are mostly concerned about overuse of templates and meta-programming, along with the lack of any API or ABI stability. Serving those C++ users requires stability and solid engineering above all, and this is what is presently missing. I am a newbe on this list, but so I am not sure whether anyone cares what I think, but I feel compelled to agree with this vision. For many
On 5/17/16 2:00 PM, Vladimir Prus wrote: projects in science, Boost is the de-facto standard library for C++. It fills the many gaps of the official standard library.
On 5/17/16 10:27 AM, David Sankel wrote:
On Tue, May 17, 2016 at 10:37 AM, Robert Ramey <ramey@rrsd.com> wrote:
Take a look at the CMake history. There was a huge effort undertaken from the top to switch to CMake for build / test. It was a failure because it tried to do it from the top down. I'm thinking that the promoters of this idea concluded that the problem wasn't ambitious enough and added deployment to the task and built rypll. This had as key collaborators our most capable and hard core developers - including David Abrahams and Eric Neibler. Huge amount of expended effort but not much came out of it.
This is a false account of what happened.
well it's my recollection and I was there. I suppose that other's might have different one though.
After the so-called top-down transition to git (which was good for C++, but bad for insiders),
I don't know if I qualify as an insider, but it seems to me that transition to Git has been a good thing and was never seen as anything else by anyone.
the steering committee somehow came to the conclusion that their job wasn't to steer.
That was one person's characterization. I think it's misleading
After last week's future of boost session (or lack-of rather), my understanding is that this is being revisited.
Boost cannot evolve the way it has in the past.
I don't think it can evolve in any other way. I think recent history, economic theory and common sense supports this.
When it was getting started, we didn't have over-representation of groups who benefit from the status-quo. We didn't have the idea of servicing the "Boost community" instead of the "C++ community". Either the steering committee will step up to protect the original vision of Boost, or the vision of Boost will change to serve the insiders.
I think this is a total misunderstanding about how boost works and has to work. The operant rule is and has to be, that people who do the work get to decide how to do it. People take initiatives and sometimes they become accepted and sometime they don't. It's evolution not intelligent design. Boost has been successful because the "system" floats the best contributions to the top while lesser one's sink to the bottom. It is not now, and can never be a democracy. If you want influence, you have to take on a task - you have earn it. Maybe it's not fair but ...
This means life or death for boost and, frankly, it's been dying over the past few years.
In part boost has been a victim of it's own success. As we filled out the capabilities of C++03 and the fundamental components got absorbed into the standard library, things were sort of winding down. This is as it should be. It should only survive as long as it's useful - it's not government institution. I think that what saved Boost is C++11. This opened up whole new territory for new libraries. It also made things like template meta programming accessible to many more people. I'm seeing another 15 years of boost success - after that? who knows? who cares? I think we're on a good path. It's a very tough job - harder than ever - and we're making head way on it as I mentioned above. And really, Other than some of C++ cohorts, I don't see much progress toward the future made by other computing initiatives. I'm optimistic. Robert Ramey
On Tue, May 17, 2016 at 12:11 PM, Robert Ramey <ramey@rrsd.com> wrote:
On 5/17/16 10:27 AM, David Sankel wrote:
This means life or death for boost and, frankly,
it's been dying over the past few years.
I think we're on a good path.
https://www.google.com/trends/explore#q=%2Fm%2F034w42%2C%20cmake%2C%20bjam&cmpt=q&tz=Etc%2FGMT%2B6
On Tuesday, May 17, 2016 at 4:32:42 PM UTC-5, David Sankel wrote:
On Tue, May 17, 2016 at 12:11 PM, Robert Ramey <ra...@rrsd.com <javascript:>> wrote:
On 5/17/16 10:27 AM, David Sankel wrote:
This means life or death for boost and, frankly,
it's been dying over the past few years.
I think we're on a good path.
https://www.google.com/trends/explore#q=%2Fm%2F034w42%2C%20cmake%2C%20bjam&cmpt=q&tz=Etc%2FGMT%2B6
I think that is a strong demonstration.
On 5/17/16 5:37 PM, Paul Fultz II wrote:
On Tuesday, May 17, 2016 at 4:32:42 PM UTC-5, David Sankel wrote:
On Tue, May 17, 2016 at 12:11 PM, Robert Ramey <ra...@rrsd.com <javascript:>> wrote:
On 5/17/16 10:27 AM, David Sankel wrote:
This means life or death for boost and, frankly,
it's been dying over the past few years.
I think we're on a good path.
https://www.google.com/trends/explore#q=%2Fm%2F034w42%2C%20cmake%2C%20bjam&cmpt=q&tz=Etc%2FGMT%2B6
I think that is a strong demonstration.
LOL - I'm not convinced. I loved the display and couldn't resist playing around with it. It only took a few seconds to generate the following: https://www.google.com/trends/explore#q=C%2B%2B%20boost Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Tue, May 17, 2016 at 7:08 PM, Robert Ramey <ramey@rrsd.com> wrote:
On 5/17/16 5:37 PM, Paul Fultz II wrote:
On Tuesday, May 17, 2016 at 4:32:42 PM UTC-5, David Sankel wrote:
On Tue, May 17, 2016 at 12:11 PM, Robert Ramey <ra...@rrsd.com <javascript:>> wrote:
On 5/17/16 10:27 AM, David Sankel wrote:
This means life or death for boost and, frankly,
it's been dying over the past few years.
I think we're on a good path.
https://www.google.com/trends/explore#q=%2Fm%2F034w42%2C%20cmake%2C%20bjam&cmpt=q&tz=Etc%2FGMT%2B6
I think that is a strong demonstration.
LOL - I'm not convinced. I loved the display and couldn't resist playing around with it. It only took a few seconds to generate the following:
Nice, you managed to do a search for 'c+boost'. While I find smoothies interesting, it is completely irrelevant to this discussion.
On 05/18/2016 12:19 PM, David Sankel wrote:
On Tue, May 17, 2016 at 7:08 PM, Robert Ramey <ramey@rrsd.com> wrote:
LOL - I'm not convinced. I loved the display and couldn't resist playing around with it. It only took a few seconds to generate the following:
https://www.google.com/trends/explore#q=C%2B%2B%20boost
Nice, you managed to do a search for 'c+boost'. While I find smoothies interesting, it is completely irrelevant to this discussion.
I do not believe it's true. I clearly see Search term: "C++ boost"
On 05/18/2016 12:22 PM, Vladimir Batov wrote:
On 05/18/2016 12:19 PM, David Sankel wrote:
On Tue, May 17, 2016 at 7:08 PM, Robert Ramey <ramey@rrsd.com> wrote:
LOL - I'm not convinced. I loved the display and couldn't resist playing around with it. It only took a few seconds to generate the following:
https://www.google.com/trends/explore#q=C%2B%2B%20boost
Nice, you managed to do a search for 'c+boost'. While I find smoothies interesting, it is completely irrelevant to this discussion.
I do not believe it's true. I clearly see Search term: "C++ boost"
More so. If one tries to search for "C++ Boost" (as Robert suggested) and for "Boost software" as you David suggested you'll immediately see that people by far prefer Robert's (I do).
On Tue, May 17, 2016 at 8:28 PM, Vladimir Batov < Vladimir.Batov@constrainttec.com> wrote:
On 05/18/2016 12:22 PM, Vladimir Batov wrote:
On 05/18/2016 12:19 PM, David Sankel wrote:
On Tue, May 17, 2016 at 7:08 PM, Robert Ramey <ramey@rrsd.com> wrote:
LOL - I'm not convinced. I loved the display and couldn't resist playing around with it. It only took a few seconds to generate the following:
https://www.google.com/trends/explore#q=C%2B%2B%20boost
Nice, you managed to do a search for 'c+boost'. While I find smoothies interesting, it is completely irrelevant to this discussion.
I do not believe it's true. I clearly see Search term: "C++ boost"
More so. If one tries to search for "C++ Boost" (as Robert suggested) and for "Boost software" as you David suggested you'll immediately see that people by far prefer Robert's (I do).
Yes, people prefer c+boost over even C++! ( https://www.google.com/trends/explore#q=C%2B%2B%20boost%2C%20C%2B%2B&cmpt=q&tz=Etc%2FGMT%2B6 ) If you move your mouse over the results, you'll see that "C+boost" was what the system looked for. When you type in "boost" in the search box you'll get the "Software" grouping disambiguator. cmake doesn't need a disambiguator. The original graph is a good reflection of reality.
David, On 05/18/2016 12:33 PM, David Sankel wrote:
On Tue, May 17, 2016 at 8:28 PM, Vladimir Batov < Vladimir.Batov@constrainttec.com> wrote:
More so. If one tries to search for "C++ Boost" (as Robert suggested) and for "Boost software" as you David suggested you'll immediately see that people by far prefer Robert's (I do).
Yes, people prefer c+boost over even C++! ( https://www.google.com/trends/explore#q=C%2B%2B%20boost%2C%20C%2B%2B&cmpt=q&tz=Etc%2FGMT%2B6 )
If you move your mouse over the results, you'll see that "C+boost" was what the system looked for. When you type in "boost" in the search box you'll get the "Software" grouping disambiguator. cmake doesn't need a disambiguator. The original graph is a good reflection of reality.
Thank you for pointing it out. Indeed, the pop-up box does show "C+boost". Still, the "Search term" box shows "C++ Boost". You seem to outright dismiss the information provided by the "Search term" box and to present the pop-up box info as the sole truth. I am far from convinced it's justified. In fact, the "q=C%2B%2B" seems to indicate that it indeed searched for C++.
When you type in "boost" in the search box you'll get the "Software" grouping disambiguator.
You seem to trust that filtering component working flawlessly. I am again not that sure. :-) More so, the numbers shown in that pop-up box are questionable... not to say outright bogus. :-)
Adding quotes solves the + problem... https://www.google.com/trends/explore#q=C%2B%2B%20boost%2C%20%22C%2B%2B%20Boost%22&cmpt=q&tz=Etc%2FGMT-3
On May 17, 2016, at 9:52 PM, Vladimir Batov <Vladimir.Batov@constrainttec.com> wrote:
David,
On 05/18/2016 12:33 PM, David Sankel wrote:
On Tue, May 17, 2016 at 8:28 PM, Vladimir Batov < Vladimir.Batov@constrainttec.com> wrote:
More so. If one tries to search for "C++ Boost" (as Robert suggested) and for "Boost software" as you David suggested you'll immediately see that people by far prefer Robert's (I do).
Yes, people prefer c+boost over even C++! ( https://www.google.com/trends/explore#q=C%2B%2B%20boost%2C%20C%2B%2B&cmpt=q&tz=Etc%2FGMT%2B6 )
If you move your mouse over the results, you'll see that "C+boost" was what the system looked for. When you type in "boost" in the search box you'll get the "Software" grouping disambiguator. cmake doesn't need a disambiguator. The original graph is a good reflection of reality.
Thank you for pointing it out. Indeed, the pop-up box does show "C+boost". Still, the "Search term" box shows "C++ Boost". You seem to outright dismiss the information provided by the "Search term" box and to present the pop-up box info as the sole truth. I am far from convinced it's justified. In fact, the "q=C%2B%2B" seems to indicate that it indeed searched for C++.
When you type in "boost" in the search box you'll get the "Software" grouping disambiguator.
You seem to trust that filtering component working flawlessly. I am again not that sure. :-)
More so, the numbers shown in that pop-up box are questionable... not to say outright bogus. :-)
The top queries for boost software(as David suggested) show things like ‘boost thread’ or ‘boost python’, which seem to be very relevant search queries, however, the ‘C++ boost’ search show top queries like ‘vitamin C’ or ‘hepatitis C’ which is completely off track.
On 5/17/16 8:49 PM, Paul Fultz II wrote:
On May 17, 2016, at 9:52 PM, Vladimir Batov <Vladimir.Batov@constrainttec.com> wrote:
David,
On 05/18/2016 12:33 PM, David Sankel wrote:
On Tue, May 17, 2016 at 8:28 PM, Vladimir Batov < Vladimir.Batov@constrainttec.com> wrote:
More so. If one tries to search for "C++ Boost" (as Robert suggested) and for "Boost software" as you David suggested you'll immediately see that people by far prefer Robert's (I do).
Yes, people prefer c+boost over even C++! ( https://www.google.com/trends/explore#q=C%2B%2B%20boost%2C%20C%2B%2B&cmpt=q&tz=Etc%2FGMT%2B6 )
If you move your mouse over the results, you'll see that "C+boost" was what the system looked for. When you type in "boost" in the search box you'll get the "Software" grouping disambiguator. cmake doesn't need a disambiguator. The original graph is a good reflection of reality.
Thank you for pointing it out. Indeed, the pop-up box does show "C+boost". Still, the "Search term" box shows "C++ Boost". You seem to outright dismiss the information provided by the "Search term" box and to present the pop-up box info as the sole truth. I am far from convinced it's justified. In fact, the "q=C%2B%2B" seems to indicate that it indeed searched for C++.
When you type in "boost" in the search box you'll get the "Software" grouping disambiguator.
You seem to trust that filtering component working flawlessly. I am again not that sure. :-)
More so, the numbers shown in that pop-up box are questionable... not to say outright bogus. :-)
The top queries for boost software(as David suggested) show things like ‘boost thread’ or ‘boost python’, which seem to be very relevant search queries, however, the ‘C++ boost’ search show top queries like ‘vitamin C’ or ‘hepatitis C’ which is completely off track.
Actually this has been entertaining on a number of levels. Could we agree that this particular tool won't be of much use to our discussion? Robert Ramey
On Tue, May 17, 2016 at 11:09 PM, Vladimir Batov < Vladimir.Batov@constrainttec.com> wrote:
On 05/18/2016 02:01 PM, Robert Ramey wrote:
Actually this has been entertaining on a number of levels.
Could we agree that this particular tool won't be of much use to our discussion?
Indeed. The only sensible conclusion possible. Moving on.
https://sourceforge.net/projects/boost/files/stats/timeline?dates=2000-06-28... -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
Le 18/05/16 à 14:16, Rene Rivera a écrit :
On Tue, May 17, 2016 at 11:09 PM, Vladimir Batov < Vladimir.Batov@constrainttec.com> wrote:
On 05/18/2016 02:01 PM, Robert Ramey wrote:
Actually this has been entertaining on a number of levels.
Could we agree that this particular tool won't be of much use to our discussion?
Indeed. The only sensible conclusion possible. Moving on.
https://sourceforge.net/projects/boost/files/stats/timeline?dates=2000-06-28...
Do you know if we can find the stats with apt-get and brew/chocolatey as well?
On 18 May 2016 at 17:04, Raffi Enficiaud <raffi.enficiaud@mines-paris.org> wrote:
Le 18/05/16 à 14:16, Rene Rivera a écrit :
On Tue, May 17, 2016 at 11:09 PM, Vladimir Batov < Vladimir.Batov@constrainttec.com> wrote:
On 05/18/2016 02:01 PM, Robert Ramey wrote:
Actually this has been entertaining on a number of levels.
Could we agree that this particular tool won't be of much use to our discussion?
Indeed. The only sensible conclusion possible. Moving on.
https://sourceforge.net/projects/boost/files/stats/timeline?dates=2000-06-28...
Do you know if we can find the stats with apt-get and brew/chocolatey as well?
..using https and a hash to verify that noone messed with these numbers while downloading them.
Le 18/05/16 à 17:13, Thijs van den Berg a écrit :
On 18 May 2016 at 17:04, Raffi Enficiaud <raffi.enficiaud@mines-paris.org> wrote:
Le 18/05/16 à 14:16, Rene Rivera a écrit :
On Tue, May 17, 2016 at 11:09 PM, Vladimir Batov < Vladimir.Batov@constrainttec.com> wrote:
On 05/18/2016 02:01 PM, Robert Ramey wrote:
Actually this has been entertaining on a number of levels.
Could we agree that this particular tool won't be of much use to our discussion?
Indeed. The only sensible conclusion possible. Moving on.
https://sourceforge.net/projects/boost/files/stats/timeline?dates=2000-06-28...
Do you know if we can find the stats with apt-get and brew/chocolatey as well?
..using https and a hash to verify that noone messed with these numbers while downloading them.
I was more thinking of this: http://popcon.debian.org/ over the same period of time ...
popularity-contest is a project dedicated to tracking installation and update statistics for Debian packages. Users have to opt in, and the web interface doesn't provide graphs that are as nearly nice as Google Trends, but the raw data may be a useful start. http://popcon.ubuntu.com/ http://popcon.debian.org/ Not sure if an equivalent exists for brew or chocolately. - Jackie On Wed, May 18, 2016 at 8:04 AM, Raffi Enficiaud < raffi.enficiaud@mines-paris.org> wrote: (snip)
Do you know if we can find the stats with apt-get and brew/chocolatey as well?
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 18 May 2016, at 17:04, Raffi Enficiaud <raffi.enficiaud@mines-paris.org> wrote:
Do you know if we can find the stats with apt-get and brew/chocolatey as well?
https://bintray.com/homebrew/bottles/boost/view#statistics Thomas
On Tue, May 17, 2016 at 10:09 PM, Vladimir Batov < Vladimir.Batov@constrainttec.com> wrote:
On 05/18/2016 02:01 PM, Robert Ramey wrote:
Actually this has been entertaining on a number of levels.
Could we agree that this particular tool won't be of much use to our discussion?
Indeed. The only sensible conclusion possible. Moving on.
Oh no you don't. 1. I showed a graph <https://www.google.com/trends/explore#q=%2Fm%2F034w42%2C%20cmake%2C%20bjam&cmpt=q&tz=Etc%2FGMT%2B6> that has no indications of bad data. It shows reasonable comparative numbers, uses proper category disambiguators, and has correct labels. 2. Robert showed another graph <https://www.google.com/trends/explore#q=C%2B%2B%20boost> that illustrated a bug in the system when using the term "C++ Boost". The fact that it is a bug is demonstrated by a.) investigation of the labels over the graph indicating "C+Boost" was the term used, and b.) comparing "C++ Boost" to C++ and seeing that "C++ Boost" has more hits, which is not a reasonable thing. 3. Folks don't understand how this system works. This can be remedied by going here <https://support.google.com/trends/?hl=en#topic=6248052>. These three points *do **not* imply that we should throw out the original graph. Just because the numbers don't support a particular position doesn't mean we should throw out all kinds of FUD over the data. The decline of Boost is real and we should face that reality. -- David Sankel
On Wed, May 18, 2016 at 8:06 AM, David Sankel <camior@gmail.com> wrote:
The decline of Boost is real and we should face that reality.
The download numbers seem to refute your claim. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On Wed, May 18, 2016 at 9:06 AM, David Sankel <camior@gmail.com> wrote:
The decline of Boost is real and we should face that reality.
Computer programming in general is on the decline, its not just Boost: https://www.google.com/trends/explore#q=computer%20programming
On 17 May 2016 at 15:32, David Sankel wrote:
This means life or death for boost and, frankly,
it's been dying over the past few years.
I think we're on a good path.
https://www.google.com/trends/explore#q=%2Fm%2F034w42%2C%20cmake%2C%20bjam&cmpt=q&tz=Etc%2FGMT%2B6
You may find my C++ Now 2014 presentation slides of interest: https://goo.gl/52bdco Lots of graphs of Boost decline :) (the absolute decline has plateaued since 2014 last time I looked, but we are still relatively declining) Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 17/05/2016 20:11, Robert Ramey wrote:
After
the so-called top-down transition to git (which was good for C++, but bad for insiders),
I don't know if I qualify as an insider, but it seems to me that transition to Git has been a good thing and was never seen as anything else by anyone. If transition to git means transition to github and modular-boost, I know at least one person who think it's a PITA.
Alain
On May 17, 2016 1:27:20 PM EDT, David Sankel <camior@gmail.com> wrote:
After the so-called top-down transition to git
What does "so-called top-down transition" mean? There was near consensus to transition, the Steering Committee decided it was worthwhile and that the preparatory work sufficient to proceed, so the SC decided we should make the transition. It's not as if the SC had a meeting to decide that Boost should switch to git and imposed its will on the community.
bad for insiders), the steering committee somehow came to the conclusion that their job wasn't to steer.
The SC's job, from the beginning, was to represent the community when necessary, which applies particularly to finances, to respond to requests for action or policy, and to make decisions for the community when needed for reasonable progress and consensus is elusive. It was definitely not formed as a governmental body directing the community. Beman, of all people, should know about the vision and intent of Boost. As a member of the SC and larger Boost Community, he's certainly in a position to question the SC's behavior relative to his vision.
Boost cannot evolve the way it has in the past. When it was getting started, we didn't have over-representation of groups who benefit from the status-quo. We didn't have the idea of servicing the "Boost community" instead of the "C++ community".
The only group I can think of that fits your description is the library maintainers. Since there are now many more than when Boost was first started, consensus becomes harder to achieve and change is harder to justify.
Either the steering committee will step up to protect the original vision of Boost, or the vision of Boost will change to serve the insiders.
I don't know what you think the SC should be doing, but hasn't done, to "Make Boost Great Again," to borrow a current, but vague, campaign slogan. ___ Rob (Sent from my portable computation engine)
On 19 May 2016 at 4:32, Rob Stewart wrote:
bad for insiders), the steering committee somehow came to the conclusion that their job wasn't to steer.
The SC's job, from the beginning, was to represent the community when necessary, which applies particularly to finances, to respond to requests for action or policy, and to make decisions for the community when needed for reasonable progress and consensus is elusive. It was definitely not formed as a governmental body directing the community.
It's funny to see the same arguments rehearsed here again. Slightly different people, otherwise same arguments. I'm going to disagree with your assertion though Rob. Looking through the original slides proposing the SC, it seems like a larger leadership role was anticipated. Dave expressed to me at the time of its creation that it was to become the new leadership, because he was getting tired of doing the never ending charge and it was becoming legally tricky for individuals to sign things for an org without having some sort of board. That original vision for the SC has since morphed into an administrative role for the SC *through the active choice of the SC* to disavow proactive leadership, but that's not your assertion here. The choice to not be proactive happened *after* the SC's creation, it was not explicitly planned to be totally hands off from the beginning. You may remember I proposed some time ago for the Steering Committee to be renamed to the "Board of Trustees" as that accurately describes your chosen function. That would open the door for the creation of an actual Steering Committee which does Steering. Unfortunately you all voted that proposal down, so it didn't happen.
Either the steering committee will step up to protect the original vision of Boost, or the vision of Boost will change to serve the insiders.
I don't know what you think the SC should be doing, but hasn't done, to "Make Boost Great Again," to borrow a current, but vague, campaign slogan.
I'd really like David to send a formal proposal to boost-steering with a specific plan please. That forces you to explicitly refuse to act again, and maybe if we keep seeing the same formal proposal being made every year it'll finally get the message through to you that you need to stop sitting on your hands. David - you may find searching the previous posts to boost-steering about leadership of use when crafting your formal proposal. Also David, if you decide to do this, feel free to run any such proposal past me beforehand. I can probably loop in a few others with an interest in this topic. I've given up on leading out any charges on this stuff after never ending recalcitrance and refusal to consider change, but I'm happy to assist you or anyone else in pushing for real change. I'd still much rather change from within than an inevitable eventual hostile fork. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On May 19, 2016 7:37:36 AM EDT, Niall Douglas <s_sourceforge@nedprod.com> wrote:
On 19 May 2016 at 4:32, Rob Stewart wrote:
The SC's job, from the beginning, was to represent the community when necessary, which applies particularly to finances, to respond to requests for action or policy, and to make decisions for the community when needed for reasonable progress and consensus is elusive. It was definitely not formed as a governmental body directing the community.
I'm going to disagree with your assertion though Rob. Looking through the original slides proposing the SC, it seems like a larger leadership role was anticipated. Dave expressed to me at the time of its creation that it was to become the new leadership, because he was getting tired of doing the never ending charge and it was becoming legally tricky for individuals to sign things for an org without having some sort of board. That original vision for the SC has since morphed into an administrative role for the SC *through the active choice of the SC* to disavow proactive leadership, but that's not your assertion here. The choice to not be proactive happened *after* the SC's creation, it was not explicitly planned to be totally hands off from the beginning.
I don't know what Dave told you, or what he intended. I do know that I was present at the meeting that established the committee. Your recollection and interpretation differ from mine. As I noted elsewhere, Beman has been involved all along and he hasn't noted, to my knowledge, any deviation from the original direction either.
You may remember I proposed some time ago for the Steering Committee to be renamed to the "Board of Trustees" as that accurately describes your chosen function. That would open the door for the creation of an actual Steering Committee which does Steering.
Unfortunately you all voted that proposal down, so it didn't happen.
I recall the name change getting serious consideration, but I don't recall the details of any decision.
Either the steering committee will step up to protect the original vision of Boost, or the vision of Boost will change to serve the insiders.
I don't know what you think the SC should be doing, but hasn't done, to "Make Boost Great Again," to borrow a current, but vague, campaign slogan.
I'd really like David to send a formal proposal to boost-steering with a specific plan please. That forces you to explicitly refuse to act again, and maybe if we keep seeing the same formal proposal being made every year it'll finally get the message through to you that you need to stop sitting on your hands.
The committee you describe is not the one I joined, as I understand things. There is, obviously, a vocal contingent asking for more., and that may well be an important, even necessary, change. Specific proposals for changes to the SC, or for the creation of a new board, are reasonable but they would need wide support in the community, not just from a vocal few. ___ Rob (Sent from my portable computation engine)
On 19 May 2016 at 11:24, Rob Stewart wrote:
There is, obviously, a vocal contingent asking for more., and that may well be an important, even necessary, change. Specific proposals for changes to the SC, or for the creation of a new board, are reasonable but they would need wide support in the community, not just from a vocal few.
Average the age of the vocal contingent. You might find it illustrative. Also note the strong correlation between the vocal contingent and those working on C++ 14 only libraries. The whole point of a proactive leadership is that they DON'T follow the masses. Most will be indifferent. Making Boost great again requires decisions not backed by a positive mass vote. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On May 20, 2016 8:05:25 AM EDT, Niall Douglas <s_sourceforge@nedprod.com> wrote:
On 19 May 2016 at 11:24, Rob Stewart wrote:
There is, obviously, a vocal contingent asking for more., and that may well be an important, even necessary, change. Specific proposals for changes to the SC, or for the creation of a new board, are reasonable but they would need wide support in the community, not just from a vocal few.
Average the age of the vocal contingent. You might find it illustrative.
I'll take that to mean you think the vocal contingent is young and the SC membership is old, on average. Assuming there is such a difference, does that mean one group is necessarily right, smarter, better, etc. than the other?
Also note the strong correlation between the vocal contingent and those working on C++ 14 only libraries.
I've not noticed a correlation beyond, perhaps, the CMake issue, but I'm not sure that C++14 is the dividing line; it may only be C++11. At any rate, splitting Boost along such a line was rejected on practical grounds, as I recall. Most don't happen to agree with you on that point.
The whole point of a proactive leadership is that they DON'T follow the masses. Most will be indifferent. Making Boost great again requires decisions not backed by a positive mass vote.
Robert has remarked numerous times that such leadership, in Boost, is expected to come from the community, not from a centralized authority. I know that frustrates you, but that is the authority structure of Boost. It is possible to develop community backing for a different structure, but that doesn't mean the Steering Committee should arrogate that role by fiat. ___ Rob (Sent from my portable computation engine)
On 21 May 2016 at 6:17, Rob Stewart wrote:
The whole point of a proactive leadership is that they DON'T follow the masses. Most will be indifferent. Making Boost great again requires decisions not backed by a positive mass vote.
Robert has remarked numerous times that such leadership, in Boost, is expected to come from the community, not from a centralized authority. I know that frustrates you, but that is the authority structure of Boost. It is possible to develop community backing for a different structure, but that doesn't mean the Steering Committee should arrogate that role by fiat.
That's by YOUR choice as the Steering Committee: you have the power, but you choose to not use it. You have *explicitly* chosen this policy which is to proactively discourage new blood and new ideas, thus enforcing the status quo. It is equal in every way to actively choosing continuing decline for Boost and the active rejection of a new generation of modern quality C++ libraries for the entire C++ community. It is in short, an anti-social, anti-younger person, anti-innovation, anti-modern, anti-real-change attitude. I know you don't understand what I'm talking about, after all we've done this topic to death on boost-steering last year, so I'll wrap up by requoting David Sankel:
Boost cannot evolve the way it has in the past. When it was getting started, we didn't have over-representation of groups who benefit from the status-quo. We didn't have the idea of servicing the "Boost community" instead of the "C++ community". Either the steering committee will step up to protect the original vision of Boost, or the vision of Boost will change to serve the insiders. This means life or death for boost and, frankly, it's been dying over the past few years.
Far more eloquently put than I've ever achieved in three years of trying to deliver this message. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On May 21, 2016 9:26:05 AM EDT, Niall Douglas <s_sourceforge@nedprod.com> wrote:
On 21 May 2016 at 6:17, Rob Stewart wrote:
The whole point of a proactive leadership is that they DON'T follow the masses. Most will be indifferent. Making Boost great again requires decisions not backed by a positive mass vote.
Robert has remarked numerous times that such leadership, in Boost, is expected to come from the community, not from a centralized authority. I know that frustrates you, but that is the authority structure of Boost. It is possible to develop community backing for a different structure, but that doesn't mean the Steering Committee should arrogate that role by fiat.
That's by YOUR choice as the Steering Committee: you have the power, but you choose to not use it. You have *explicitly* chosen this policy which is to proactively discourage new blood and new ideas, thus enforcing the status quo. It is equal in every way to actively choosing continuing decline for Boost and the active rejection of a new generation of modern quality C++ libraries for the entire C++ community.
It is in short, an anti-social, anti-younger person, anti-innovation, anti-modern, anti-real-change attitude. I know you don't understand what I'm talking about, after all we've done this topic to death on boost-steering last year, so I'll wrap up by requoting David Sankel:
Boost cannot evolve the way it has in the past. When it was getting started, we didn't have over-representation of groups who benefit from the status-quo. We didn't have the idea of servicing the "Boost community" instead of the "C++ community". Either the steering committee will step up to protect the original vision of Boost, or the vision of Boost will change to serve the insiders. This means life or death for boost and, frankly, it's been dying over the past few years.
Far more eloquently put than I've ever achieved in three years of trying to deliver this message.
We're obviously talking past one another and I don't know how to resolve this. ___ Rob (Sent from my portable computation engine)
On 5/21/16 6:26 AM, Niall Douglas wrote:
On 21 May 2016 at 6:17, Rob Stewart wrote:
This sort of sums up the differences. At the risk of repeating myself again (recursion) I'll add to this (moth to the flame).
The whole point of a proactive leadership is that they DON'T follow the masses. Most will be indifferent. Making Boost great again requires decisions not backed by a positive mass vote.
No doesn't the reason boost is great is because expressily avoids doing this.
Robert has remarked numerous times that such leadership, in Boost, is expected to come from the community, not from a centralized authority. I know that frustrates you, but that is the authority structure of Boost. It is possible to develop community backing for a different structure, but that doesn't mean the Steering Committee should arrogate that role by fiat.
That's by YOUR choice as the Steering Committee: you have the power, but you choose to not use it.
True - and a very wise choice indeed!
You have *explicitly* chosen this policy which is to proactively discourage new blood and new ideas, thus enforcing the status quo.
Not at all - the steering committee has declined to intervene except when absolutely necessary. It hasn't encouraged or discouraged anything.
It is equal in every way to actively choosing continuing decline for Boost and the active rejection of a new generation of modern quality C++ libraries for the entire C++ community.
The only active rejection of new libraries are libaries which are not deemed to meet Boost's standards and policies. And this judgement is not rendered by the steering committee - but by the community members who spend there own time investigating and reviewing submissions. The steering committee has no role in this process.
It is in short, an anti-social, anti-younger person, anti-innovation, anti-modern, anti-real-change attitude. I know you don't understand what I'm talking about, after all we've done this topic to death on boost-steering last year, so I'll wrap up by requoting David Sankel:
ROTFL - Ahhh so the whole problem is that I'm too old to understand the argument! It's even worse - I'm too old to even understand that I AM too old!! (it's that damn recursion again) And it's even worse - I have a bad attitude towards young people! That's the problem!
Boost cannot evolve the way it has in the past. When it was getting started, we didn't have over-representation of groups who benefit from the status-quo. We didn't have the idea of servicing the "Boost community" instead of the "C++ community".
Either the steering committee will step up to protect the original vision of Boost,
The steering committee has been hands off. This is the best thing it can do to protect the original vision of boost. using constitutional government as an analogy, the steering committee isn't the president or cabinet which runs the country, it's the supreme court to administers the basic rules under which the varied interests fight it out. I'm aware that the steering committee was only formed in 2008 but that role was originally performed by a secret cabal of insiders. Their genius was to keep their role limited.
or the vision of Boost will change to serve the insiders.
The current vision of boost serves those members/participants in more or less in proportion to the scale, utility, and appreciation for their contribution. Those who make the build system get the authority to decide how to do it. Those who make libraries get the authority to decide how it gets done. So it's true that the "insiders" have disproportionate say. I'm aware that this is grating to some but changing this would be the end of boost as we know it. Boost is uniquely successful because of this vision. And you're right - it's not going to change. It's not going to evolve in the way you envision.
This means life or death for boost and, frankly, it's been dying over the past few years.
To be replaced with ... what exactly. You're proposals amount to setting aside all that is boost and just keeping the name. Why waste your time and everyone's time trying to convince us that this is a good idea. Why not just fork boost and make it in your own vision. I'm absolutely mystified by this. No one would object to this. You can use all the boost code. There is only one thing you can't take with you and that's boost name (and bank account of course). Everything else is at your disposal. Is that not enough? Why do you need more? And it's ridiculously easy to do - just fork boost, Insert a CMakeLists.txt file in the root of each library, and announce a new name. What do you need us "insiders" for. Without us old farts holding you back, you'll take off like a rocket and we'll just wither away into irrelevance (at a personal level I can already feel this happening).
Far more eloquently put than I've ever achieved in three years of trying to deliver this message.
Don't be too hard on yourself. You delivery and advocacy are fine and actually quite effective. The problem is that the idea you're trying to promote is spectacularly bad and most people see this. Robert Ramey PS a personal note: I stumbled on boost around the year 2000 while looking for a sane wrapper around mswindows and posix threading libraries. It was a revelation to me. I've spent a life time dealing with crappy code, people who think their crappy code is great, arguing with people who refused to test code, refuse to use const and engaging in all manner of hacking and really bad ideas. And then when one points out the obvious, he is subjected by a whole tirade that he doesn't know what he's talking about, that he's stupid, that it's so obvious it doesn't require an argument, that everyone does it this way, that .... all manner of pointless circular fact free argument. When I came upon boost it was a revelation. First, a sensible discussion policy. Then a formal methodology for quality assurance including serious testing and peer review process. The ideas weren't revolutionary, but it was the first public institution which took them seriously and it has made all the difference.
On May 19, 2016, at 3:32 AM, Rob Stewart <rstewart@ptd.net> wrote:
On May 17, 2016 1:27:20 PM EDT, David Sankel <camior@gmail.com> wrote:
After the so-called top-down transition to git
What does "so-called top-down transition" mean? There was near consensus to transition
I don’t remember there being consensus.
, the Steering Committee decided it was worthwhile and that the preparatory work sufficient to proceed, so the SC decided we should make the transition. It's not as if the SC had a meeting to decide that Boost should switch to git and imposed its will on the community.
bad for insiders), the steering committee somehow came to the conclusion that their job wasn't to steer.
The SC's job, from the beginning, was to represent the community when necessary,
The purpose of the steering committee is to protect the vision of boost.
which applies particularly to finances, to respond to requests for action or policy, and to make decisions for the community when needed for reasonable progress and consensus is elusive. It was definitely not formed as a governmental body directing the community.
Beman, of all people, should know about the vision and intent of Boost. As a member of the SC and larger Boost Community, he's certainly in a position to question the SC's behavior relative to his vision.
As well as David Abrahams would know the purpose of the SC, and its purpose and intent is not for what you said.
Boost cannot evolve the way it has in the past. When it was getting started, we didn't have over-representation of groups who benefit from the status-quo. We didn't have the idea of servicing the "Boost community" instead of the "C++ community".
The only group I can think of that fits your description is the library maintainers. Since there are now many more than when Boost was first started, consensus becomes harder to achieve and change is harder to justify.
Either the steering committee will step up to protect the original vision of Boost, or the vision of Boost will change to serve the insiders.
I don't know what you think the SC should be doing, but hasn't done, to "Make Boost Great Again," to borrow a current, but vague, campaign slogan.
He’s referring to the meeting that happened at C++Now with the future of boost. Unfortunately, I believe that its not recorded. Perhaps someone else can pass along some notes of this meeting. Thanks, Paul
a) modular deployment and dependency management. No surprise here as this is a job of major, major difficulty. b) policy for library deprecation - not really hard but really very low priority.
Just out of curiosity: is there a concept for this? I have a few ideas for that: Make the submodules targets in boost.build. That is, if I want to build a submodule, e.g. 'b2 --with-filesystem' will also pull the submodule. That would also apply for references, e.g. if I build boost.dll it will automatically require the build of boost.filesystem, so if it references /boost/filesystem, this will pull this one. I have an idea how that could be implemented in boost.build (by declaring the submodule/.git a target). I know that the --with-library parameter only works for those with binaries, but that does not have to be that way. This would speed the CI build up immensely (currently most of them checkout all submodules) and secondly allow partial deploys by just setting a list of the submodules to be included in the build. That would be the simplest form of package-managing (though source isn't really a package) but would imho be rather easily implemented. Also the CI would then test if the dependencies are set correctly. Thus we could provide a version to build a partial set of the boost libraries from github; if a downloadable archive should be provided it would then also be possible to run bjam to just pull the submodules and delete the empty ones, so we could provide a fast way to generate an archive with the correct dependencies. Now if this approach would work, it would be incredible easy to generate your own package of boost, so it wouldn't be a big problem if some libraries get deprecated. They wouldn't even have to be a submodule, since adding a submodule is very simple. The build-system already automatically searches the subfolders. Secondly, as for the deprecation, I'd think the most obvious way to group boost libraries is by the C++ Standard. So basically: boost.lambda is not included with Boost-11, Boost-14 would include boost.hana, but deprecate boost.fusion etc. The current would of course be boost-1z. If an old version is than no longer maintained, well, if someone needs it, he should maintain it. Would be easy enough with that approach. That would mean: if a library gets deprecated, there is a replacement in either the new boost version or the standard. We would however break code, but since it's easy to setup a custom boost-config, you can include the deprecated library in your own. Thirdly, a <standard> parameter in boost.build would be nice (and easy) and thus a library maintainer could better structure his library. Also there could be an error if someone attempts to build a library with a too old standard. Additionally it could be differenciated between two versions of a library, by having different 'master' branches. Though I haven't thought that through yet, i.e. how that would be implemented in boost.build. I think the build should then look like this: b2 //builds the current version, i.e. boost-1z b2 standard=11 //builds the 11 version b2 standard=11 package-list=my_list //builds only whats in my_list I think I can help with the boost.build implementation, but I would of course be interested in what you think of those ideas.
On 17 May 2016 at 11:37, Robert Ramey <ramey@rrsd.com> wrote:
There is one big lesson from all this:
a) Boost is not a company - we don't take direction from the top. b) Boost is not a government - we actually do something. c) Boost is a religion - want something changed, start preaching. Get other people on board. Convince people people to start doing something.
Boost is not a religion. It's a set of tools; no more, no less. Does Boost have to evolve? Of course it does, because the world around it has evolved. It came about when it was 13 years between releases of the standard, and there were a lot of obvious-in-retrospect libraries (especially vocabulary types) missing (shared_ptr, function, optional, variant, any, etc.). Now it is 3 years between standard releases, and in some ways making a proposal directly to the committee is easier if you want to get your library out there: shorter commitment, only need one implementation, no need to support that implementation for years under multiple compilers, etc. -- Nevin ":-)" Liber <mailto:nevin@cplusplusguy.com <nevin@eviloverlord.com>> +1-847-691-1404
On Thursday, May 19, 2016 at 12:09:32 PM UTC-5, Nevin Liber wrote:
On 17 May 2016 at 11:37, Robert Ramey <ra...@rrsd.com <javascript:>> wrote:
There is one big lesson from all this:
a) Boost is not a company - we don't take direction from the top. b) Boost is not a government - we actually do something. c) Boost is a religion - want something changed, start preaching. Get other people on board. Convince people people to start doing something.
Boost is not a religion. It's a set of tools; no more, no less.
Does Boost have to evolve? Of course it does, because the world around it has evolved. It came about when it was 13 years between releases of the standard, and there were a lot of obvious-in-retrospect libraries (especially vocabulary types) missing (shared_ptr, function, optional, variant, any, etc.). Now it is 3 years between standard releases, and in some ways making a proposal directly to the committee is easier if you want to get your library out there: shorter commitment, only need one implementation, no need to support that implementation for years under multiple compilers, etc.
Which is unfortunate. C++ standard committee should focus on standardizing existing practice. The boost process helps create a larger feedback and implementation experience, and would help avoid major gaffes like _v variable templates. Not everyone can give feedback at standards meetings, but it is fairly easy to give feedback during a formal review of a library for boost.
On 05/20/2016 03:08 AM, Nevin Liber wrote:
On 17 May 2016 at 11:37, Robert Ramey <ramey@rrsd.com> wrote:
There is one big lesson from all this:
a) Boost is not a company - we don't take direction from the top. b) Boost is not a government - we actually do something. c) Boost is a religion - want something changed, start preaching. Get other people on board. Convince people people to start doing something. Boost is not a religion. It's a set of tools; no more, no less.
Clearly Robert was metaphorically speaking and explained well what he meant -- "want something changed, start preaching"... Maybe a bit too strong but still...
... in some ways making a proposal directly to the committee is easier if you want to get your library out there: shorter commitment, only need one implementation...
I personally far from sure that's a good idea. IMO Boost has been an excellent (and essential) preparatory platform (and a safeguard) for potential/future std inclusion.
On 5/19/16 2:20 PM, Vladimir Batov wrote:
On 05/20/2016 03:08 AM, Nevin Liber wrote:
On 17 May 2016 at 11:37, Robert Ramey <ramey@rrsd.com> wrote:
There is one big lesson from all this:
a) Boost is not a company - we don't take direction from the top. b) Boost is not a government - we actually do something. c) Boost is a religion - want something changed, start preaching. Get other people on board. Convince people people to start doing something. Boost is not a religion. It's a set of tools; no more, no less.
Clearly Robert was metaphorically speaking and explained well what he meant -- "want something changed, start preaching"... Maybe a bit too strong but still...
LOL - not it's not. The point is that Boost is not the hierarchical organization you're probably currently working it. We don't take orders from the top and execute them. We don't take our ideas up the chain and wait for someone to approve them and wait for them to come down again. Again, and again, something happens - like quickbook which gets invented and spreads horizontally. This is why I think Naill's approach, difficulties resulted in so much frustration. It pains me because I know he's worked hard on trying to make changes. But on the other hand - look at eh GSOC program. It seems to me he took more of the bottom up approach and was a lot more successful at it. This is really what I mean. And we can work this way because were motivated by passion. How else could we sustain a discussion like this for days - (not that this is a good thing - it's just a fact). So if you care about Boost/C++ and want to make better, it's best to understand how this works (or doesn't work). Just my 2 cents. Robert Ramey
... in some ways making a proposal directly to the committee is easier if you want to get your library out there: shorter commitment, only need one implementation...
I personally far from sure that's a good idea. IMO Boost has been an excellent (and essential) preparatory platform (and a safeguard) for potential/future std inclusion.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 19 May 2016 at 15:11, Robert Ramey wrote:
This is why I think Naill's approach, difficulties resulted in so much frustration. It pains me because I know he's worked hard on trying to make changes. But on the other hand - look at eh GSOC program. It seems to me he took more of the bottom up approach and was a lot more successful at it. This is really what I mean.
I don't invest my charity time on things not supported by a network of others - otherwise you just build ivory towers no one else is interested in. You need collective buy in to achieve change. Boost GSoC is supported by a ton of people who made everything I've achieved as lead admin possible. We've also seen substantial buy in from the Steering Committee who have spent a LOT of money on GSoC. That's what made that possible, not some "bottom up approach" - on my work there I have been very amply supported by others. For making Boost great again I keep coming back to the fact that some *group* - not me or you or anybody individually - with the recognised authority to decide on global strategy needs to make a decision. That group is the Boost Steering Committee. (whom, just to be clear, cannot act on anything without someone submitting a formal proposal. So a formal proposal needs to be sent to boost-steering, and they'll vote on it next meeting) Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 5/20/16 5:32 AM, Niall Douglas wrote:
On 19 May 2016 at 15:11, Robert Ramey wrote:
This is why I think Naill's approach, difficulties resulted in so much frustration. It pains me because I know he's worked hard on trying to make changes. But on the other hand - look at eh GSOC program. It seems to me he took more of the bottom up approach and was a lot more successful at it. This is really what I mean.
I don't invest my charity time on things not supported by a network of others - otherwise you just build ivory towers no one else is interested in. You need collective buy in to achieve change.
Right. I'm amazed you would think that you could get collective buy in to your proposal. Especially given your dedication to what to me should be obvious as a non-starter.
Boost GSoC is supported by a ton of people who made everything I've achieved as lead admin possible. We've also seen substantial buy in from the Steering Committee who have spent a LOT of money on GSoC. That's what made that possible, not some "bottom up approach" - on my work there I have been very amply supported by others.
Right.
For making Boost great again I keep coming back to the fact that some *group* - not me or you or anybody individually - with the recognised authority to decide on global strategy needs to make a decision. That group is the Boost Steering Committee.
Wrong. It's not the steering committee that drives anything. It's user demand and willingness/passion of library authors who do the the work. Neither the steering committee nor anyone else can control that. They can only react to it when circumstances change to the point that they cannot be ignored. This is not just boost, it's universal.
(whom, just to be clear, cannot act on anything without someone submitting a formal proposal. So a formal proposal needs to be sent to boost-steering, and they'll vote on it next meeting)
LOL - even that's hard to make happen. Robert Ramey
participants (19)
-
alainm -
David Sankel -
degski -
Hans Dembinski -
Jackie Kay -
Klemens Morgenstern -
Nevin Liber -
Niall Douglas -
Paul Fultz II -
Peter Dimov -
Raffi Enficiaud -
Rene Rivera -
Rob Stewart -
Robert Ramey -
Thijs van den Berg -
Thomas Trummer -
Vinnie Falco -
Vladimir Batov -
Vladimir Prus