I'll say that I checked it out and looked at the category page - it appears that nothing is categorized so it looked like nothing was there. ________________________________________ From: Boost on behalf of Mostafa Sent: Wednesday, November 5, 2014 3:48 PM To: boost@lists.boost.org Subject: Re: [boost] Boost Incubator Status Report On Wed, 05 Nov 2014 09:42:07 -0800, Robert Ramey wrote: [snip]

e) I would like to see a little more support from Boost Steering Committee on this effort.

As a starting point, a link from the official Boost home page and Boost libraries download page would probably generate more traffic. Of course, with the usual caveat that these are not Boost libraries nor endorsed by Boost, etc... _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Niall Douglas wrote

On 5 Nov 2014 at 9:42, Robert Ramey wrote:

...

e) I would like to see a little more support from Boost Steering Committee on this effort. Specifically I would like to see the Announcement that Boost endorses the Boost Library Incubator (www.blincubator) packaged and distributed as press release so that it would show up in places like Dr Dobbs Journal. (http://www.drdobbs.com) and isocpp.org (http://isocpp.org). It is a great disappointment to me that in spite of a fair amount of effort, I've been unable to get these sites (among others) to announce the Boost endorsement of Boost Library Incubator.

The lack of SC support for your Incubator came up in private email recently. It was observed that it was surprising that the SC had not invested money and allocated bodies in helping to advance your Incubator, and instead merely given a weak statement of vague support which got swallowed by noise.

FWIW - I'm not asking for money - I'm only asking for a press release and a little push to get it announced on the isocpp.org website. I don't think that that's a lot to ask - especially given the stuff I do see announced there.

It was then observed that no formal request for anything but a statement of support had been made, and so therefore nothing more than a statement of support was given.

Great - I got that - now I've been asking for a press release sent under the official Boost Steering Committee Aegis sent to the appropriate parties along with a push to get it the announcement and link into the the ioscpp.org web site. That doesn't need any money. I don't think it's an unreasonable request.

It could be concluded that if you formally ask for more, you might get more.

LOL - it could also be concluded that if one can't get something that costs nothing - it's pointless to ask for financial support.

If I were you Robert, I'd make a formal request to the SC for each of the following:

1. Financial support for the running of the Incubator.

2. The hiring of Wordpress consultancy to advise you where you have been having some struggle.

3. The hiring of someone to deeply integrate the Incubator into the Boost website. This could be the consultancy from 2.

4. Begin work on drafting new rules for submitting a new Boost library to default to the Incubator, the old method of going via the wizards is removed.

... and see what happens.

I really appreciate the advice and the good will in offering it. But I have to say I have a whole different way of looking at how the world works. TL;DR;

1. Financial support for the running of the Incubator.

I honestly don't think financial support would help anything. I do this in my spare time and it doesn't take all that amount of time. The main thing is that I don't really like making this thing work - it's not my think. And a wordpress expert could probably do it in half the time I can... But financial support wouldn't create time.

2. The hiring of Wordpress consultancy to advise you where you have been having some struggle.

Monitoring and managing a wordpress consultancy would probably cost more time than I currently spend on it. Ideally I'd like help from a someone who spends time on this as part of his job. As an aside I'd say that: a) Wordpress, like all web design is a pain. b) Wordpress, like many web design framework delivers huge functionality for relatively few lines of code. Its an excellent learning experience for the hard core C++ programmer. Its a window on where we're missing the boat and how far we can and actually must eventually go. It's an anti-dote to the narrow perspective that we have from sticking to boost/C++/Standard conferences. c) Actually the incubator has most of the functionality it needs already. So more resources for enhancement would be useful but not urgent. The soon to be working "sponsorship" opportunities will also apply to web page enhancement - so maybe someone will step up just to get free exposure to all the C++ eyeballs which you guys are going to send to the page.

3. The hiring of someone to deeply integrate the Incubator into the Boost website. This could be the consultancy from 2.

I think the Boost Website needs an upgrade and re-thinking. I don't think anything should be "deeply integrated" into it. Currently it's not dynamic enough. That's why we have a lot of important pages added to the trac wiki. Thats why the Boost Steering Committee made its own website. Ideally this Boost website should be more of a "facade" or something more like the Boost Library Incubator is now where separate pages/posts/components can be composed/re-composed very easily. Wordpress is actually very good at this. In this scenario the Incubator could be just linked into something which looks seamless. You can see my thinking in the incubator itself. It's really a seamless facade over disparate repos, issues, docs, etc to make it look like integrated. I leveraged on all the other stuff that's out there - and I can drop any of it in an instant. This is the way of the future. Note I didn't even have to steal or copy anything - I just linked it all. The time is spent on figuring out how to link it together. In this context, "deeply integrating the incubator" disappears as a task.

4. Begin work on drafting new rules for submitting a new Boost library to default to the Incubator, the old method of going via the wizards is removed.

What I would like to see is: a) Those who comment on libraries are encouraged to add them to the incubator. This makes them available permanently to anyone who is interested in a prospective library. b) Users of libraries in the incubator are encouraged to add formal reviews. c) The review wizard states that when time is appropriate for a review - not in the middle of release or some other fiasco. There hasn't been a review for a while, and there are worthy candidates in the review queue, i) he will select the next library for review giving priority to any libraries which already have the most number of "pre-reviews" in the incubator. 2) reviewers are encouraged to post their reviews in the incubator. The first time this happens it will be sort of "test run" of the system which I realize might not be successful. Even if recognized as successful, surely it would indicate the need for corrections and/or enhancements. (I'm a great believer in evolution vs intelligent design). I think there's wide agreement that boost needs to evolve and I see significant efforts in this direction - modularization, incubator. This is a good thing. It seems that one vision is of boost evolving to a stronger, and better funded organization and more influential organization with a beefed up infrastructure. The idea is that this would permit it to continue to grow in spite of the increase in costs that this entails. I disagree with this vision - I think it gets things upside down. And I think boost should be looking at ways to shrink infrastructure requirements. I see the future boost looking like: a) Website composed of links to other ideas - much like we've done with modularized libraries, incubator etc. b) I would like to see testing outsourced to users. That is, when you download a library, you're encouraged to run the tests and the test results get posted to the common dashboard. Boost would be responsible for seeing that the dashboard works. c) I would like to see deployment of Boost outsourced so software distributors like Cygwin, Debian, Microsoft, and who knows who else. A Boost certified distribution wouldn't necessarily contain all the libraries. There might be a subset of graphics useful ones distributed by CGal and/or Cinder. There might be a math subset distributed by CERN. There might be threading one distributed by Intel as part of TBB. etc. This would 1) implement an effective way of deprecating libraries. Out of date/Obsolescent libraries wouldn't be "de-certified". It's just that distributors would decline to include them. 2) Permit Boost to get ever bigger without users having to deal with ever bigger distributions. The problem isn't so much the size of the distributions. The problem is more that when the distribution get's big, the chances increase that there's a snafu which inhibits testing/building but isn't really related to the actual functionality which one is interested in. 3) This would evolve the role of boost from Review, Testing, Deployment to a role of Review/Certification d) I would hope that Boost doesn't evolve to a funding organization. This would be a source of more disputes. I would prefer to see. 1) encourage of a mechanism where interested parties sponsor more specific functions/libraries. Examples, - How about Lockeed F-35 development organization funding or implementing the functionality in Safe Numerics. Can you believe that the actually code this thing in C++ without some sort of functionality like this? It would be absolutely crazy - but I bet they do it. The could get this functionality for .000000001 % of what they currently spend. Alternatively, they could be encouraged to develop it themselves and make it open source so the rest of can test it, reject it, certify it and/or debug/improve it. I've been waiting for a call here, But so far the phone hasn't rung. - How about getting ? to sponsor the CMake page in the incubator? That would be useful and they could flog there stuff - Actually I'll try to get them to maintain the page in exchange for including their logo. Wish me luck. - How about getting NVidea or ? to sponsor the library Boost Compute. Anyone who expresses an interest in SIMD computing can not be subjected to an NVidea logo and link. Of course NVidea wouldn't get that for free -they need to work it out with the author. - How about getting Toyota and other car makers to support enhancement of Boost Concept Checking so they diminish unexplained acceleration. - How about getting US Department of health and human services to sponsor Boost Test and/or Boost Mock to diminish the Obamacare website fiascos. Heck the already spent 500 million $ for the worlds record time waster - I'm sure the authors of these packages would love to get a $100,000 check in the mail. I suppose I belabored the point - oh well. In short the trick to permuting boost to grow is to expect it to do less!!!! All of the above would require a) us getting resolved issues of dependencies. Progress has been made here but there are still issues to be addressed. b) making a new versioning scheme. c) A re-thinking the website. I'm sorry I got carried away I work alone and don't have anyone to talk to. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Incubator-Status-Report-tp4668747p4... Sent from the Boost - Dev mailing list archive at Nabble.com.

Niall Douglas wrote

I also think that Wordpress is very good at what it does, but anything involving review of other people's work it is truly terrible at. It's just not designed for it, ...

I looked a large number of systems and spend significant time in evaluating at least five. My method was: - read the explanation - If it wasn't documented - done, if the documentation wasn't understandable - done - try installing - if it wasn't easy to install - done - try using the system, examples, whatever to make a prototype boost incubator. I probably was willing to spend a couple of hours on I tried making prototypes of the incubator using no less than five other systems. These systems varied all over the place. Some simple, some elaborate, some widely supported with add-ons others not, some well documented, others not. etc. etc.. When wordpress looked like it could be made to do the job - I got on with the job. I have a love/hate relationship with wordpress - but I have that relationship with everything. when the incubator first came out - I got all sorts of suggestions that it would have been better to use system X, Y, ... . Of course no one actually volunteered to implement the incubator in them. So I just pushed on. That's my method - push on. All that said, my experiences there and my failed Web 2.0 startup in 2011 probably make me unusually familiar with web technologies for a C++ engineer. And I baulk at the complexity of what you are intending to do alone LOL - I'm happy to let someone contribute! But so far that hasn't happened. and without substantial financial support. financial support is overrated. This is a holy quest. We need zealots - not mercenaries. I don't know what I would spend money on. I originally made the incubator with the idea that someday boost might want to take it over and make it part of boost.org. I still would like to see that - but I don't see how that would actually help/change anything. You really need at least three full time engineers on the Incubator if you expect to deliver something usable within six months (don't forget the unit testing! Well designed web services have enormous automated test suites which probe the website in real time for anything going wrong, and they run 24/7. Setting those up properly makes writing comprehensive C++ testing look like a doddle). Good web engineers are perhaps even more rare than good C++ engineers, plus there is 10x more web engineers who think themselves god's gift when they are mediocre at best (more noise to signal). And good web engineers are expensive, Google pays its about 10% more than programmers for good reason, not least the shortage of talent. This is very interesting to me and explains a lot regarding the problems of modern computer applications - think obamacare website. I don't doubt that one has to pay developers of web applications more than C++ programmers. Tax lawyers make more money too. The problem is that we've created a system which is a giant complex hack that no one with any respect for logical elegance would waste his time on without getting paid a lot.

...

2. The hiring of Wordpress consultancy to advise you where you have been having some struggle.

c) Actually the incubator has most of the functionality it needs already. On that we disagree. I don't find the Incubator usable, particularly

maybe - I'd appreciate any real help. If someone want's to hire a web consultancy to do some of the work great. If they do please let me know as I would like to hire on as a consultant to the consultants to consult on the requirements and functionality of the system. Funny you say that actually. Wordpress, compared to the other CMSs, is very distinctly an anti-pattern - it intentionally chooses a simple, inflexible design in exchange for reliability, predictability and security, and it's the only PHP based CMS I know of to have achieved reasonably good security. In that success the anti-pattern was a wise choice, but boy is Wordpress inflexible as a result. You're way too generous - they all suck. If it were up to me I would do it all in C++. But the need to leverage pre-existing functionality trumped everything else. My experiments convinced me that wordpress was/is the best of a bad lot. But you also get that horrible feeling of utter ignorance that anyone starting into C++ gets - Plone/Zope is full of ingenious design patterns, ones which make C++ look fusty and backward, but due to its maturity there are many islands of such design patterns none of which entirely fit together well to the inexperienced. In other words, just like C++, Boost and the STL. LOL - I never heard of this so I never looked at it. Sounds like I dodged a bullet. the commenting feature. I don't think the threaded commenting approach works for code review. That's what we use on the developer list for formal reviews. In my 12 years being involved in boost - no one has ever suggested that the formal review processes needs this sort of functionality. The incubator formal review is pretty much identical to the current one - just a little more form oriented. That's what I was aiming for. A line or file or issue based commenting approach is much better, but even then a decent summary review would be paramount. Now if you believe that boost should change it's formal review process in some way - that's fine - but the incubator doesn't aim to to that. Some voting and scoring system is needed too. Boost acceptance is not based on voting. The library incubator has installed a system for voting/rating etc. (not that it's needed much as there is only one review so far) As you know, I stand pretty much opposite to you on your vision of the future for Boost, We don't disagree on everything. We both agree that Boost has to evolve. I look at the most successful open source orgs and what they do and we do not, and I think we should copy them. I'm not sure which open source orgs are more successful than boost. The ones that occur to me like gcc, mysql, etc. Are built around "products" so I'm not convinced they are good models for us. Boost has been VERY successful. That, as you correctly observed, means Boost turns into a funding acquisition and dispensing machine which actively promotes its vision of the future of C++ by obtaining funding and dispensing funding on the items it thinks will return the most benefits to its future. Very different to before of course, it's more of an open source business than anything involving coding and the skills demanded are managerial and business ones, not engineering. But that's the marketplace right now, we either have to step up to compete or wither in the face of competition. We're 180 degrees apart on this. I think Boost has to aim to do less, outsource everything it can, become smaller, and more "agile". It has to look less like a "product" where development is the responsibility of some sort of concensus procedure and more like a "marketplace" where the central authority confines itself the to the "rules of the game" and lets the chips fall where they may. And the incubator is a manifestation of this. It's not the result of a consensus and/or compromise in some sort of committee. It's one man's (hopefully) logically coherent vision of a feature to be added to boost - which Boost can choose to embrace or ignore. -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Incubator-Status-Report-tp4668747p4... Sent from the Boost - Dev mailing list archive at Nabble.com.

Gordon Woodhull wrote

I don't think Robert ever intended the Incubator to replace the formal review or the role of the Wizards.

Instead, IMO it is better thought of as a replacement for the unscheduled part of the review schedule (aka the Queue), and a better way to verify the basic requirements for submitting a library. And reviews can be submitted and responded to before the formal review, without getting buried in the mailing list.

Basically correct. I think the boost review process has been the single most important innovation that boost has made. I believe that without this idea - boost (and C++) would not be where they are today. The fact that it is NOT a voting process but places the final decision in the hands of one publicly named person makes it entirely different than other attempts at evaluating software. Software quality is not determined by consensus but rather by people making decisions they must take responsibility for. My intention is to preserve all of the above - just make it easier to use. One aspect - the 1-2 week period is a good idea - but couples reviews to a narrow window. The main idea of the incubator is to permit reviews to be made when a reviewer is ready to do it - and save them for later. Again- I don't think the review process itself needs any change - we just need more reviews and that's what I'm trying to accomplish. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Incubator-Status-Report-tp4668747p4... Sent from the Boost - Dev mailing list archive at Nabble.com.

On 6 Nov 2014 at 12:15, Vladimir Prus wrote:

Personally, I would say incubator would need considerable work before it can become useful for library reviews. Say, if I can made per-line comments on proposed library code, like gerrit does, it would be rather useful. If I can create design issues right away, so that they can be listed later and reviewed, it would be rather useful. It does not appear to me that wordpess post with comments is better than a thread in a mail client. At least mail client allows to collapse a subthread, or delete it.

Github provides an excellent API (https://developer.github.com/v3/repos/comments/) which does exactly as you ask. Even a read only summary of the comments posted about a library would be very useful. And not too demanding on Github if cached via a varnish reverse proxy (i.e. we don't have to pay Github for the bandwidth). I also wouldn't rule out using JSON to live embed the github stream into the Incubator. Github eats its own dog food, so you can make a mashed up Incubator reinterpretation of Github with Incubator semantics. Then people can live review code on the Incubator, and it appears in Github too. This is where I was coming from with having the SC pay for expert advice and consultancy. This sort of web programming pays as well as top C++ programmers, and for good reason, yet it is none of our core competency. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

Vladimir Prus-3 wrote

Rather, the question is what we're trying to really achieve. One can come up with all sorts of things, like:

- Gather interest on potential new libraries - Easily comment on code - Easily comment on documentation - Run tests on potential submissions

and these can have multiple technical solution, like using social networks, gerrit-style code annotation, medium-style documentation comments, and changes to the test framework, but it does not appear there's a decision what we want to achieve.

The above list doesn't describe what MY goals for the incubator are. I'm not saying they're necessary unworthy - just that i haven't had them in mind. Here is what intend to achieve with the Boost Library Incubator - Increase submissions of quality libraries by: - giving advice on how to do it - and allowing others to post their own advice if they disagree. - providing a place where the current state of a library can be found and displayed - promote the testing of libraries by users on their own machines and the posting of results to a common area. - promote the concept of sponsorship of library authors by deep pockets organizations who depend upon specific libraries. - Promoting and supporting the Boost Review format and system by: - de-coupling the review from a specific time frame. - Keeping comments and reviews linked to library for future reference by users looking to use a library. - Increase the usage of boost and pre-boost libraries by providing potential users more information: - providing an amazon-like system for rating libraries based on reviews. - Keeping comments and reviews linked to library for future reference by users looking to use a library. - Defining a minimal but universal set of requirements including - Browsable documentation - library tests - boost compatible directory structure - Build/Test system And of course subject to the constraint that I can actually make a system which does this in a short amount of time and resources so that the system can evolve. This is pretty concise list of what I hope to achieve. I'm pleased with the results regarding some of the goals, less pleased with others. But I'm hoping with a little incremental tweaking, I'll continue to make progress. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Incubator-Status-Report-tp4668747p4... Sent from the Boost - Dev mailing list archive at Nabble.com.

2014-11-11 14:36 GMT+01:00 Vladimir Prus :

On 11/06/2014 07:43 PM, Robert Ramey wrote:

...

Vladimir Prus-3 wrote

...

Rather, the question is what we're trying to really achieve. One can come up with all sorts of things, like:

- Gather interest on potential new libraries - Easily comment on code - Easily comment on documentation - Run tests on potential submissions

and these can have multiple technical solution, like using social networks, gerrit-style code annotation, medium-style documentation comments, and changes to the test framework, but it does not appear there's a decision what we want to achieve.

The above list doesn't describe what MY goals for the incubator are. I'm not saying they're necessary unworthy - just that i haven't had them in mind.

It's hard to say which goals are best; in fact I'm not sure we have universal agreement on what are the problems, and what are the reasons for them.

I've just created a quick poll on Google+ about our review process, it would be great if anybody who cares express their opinion:

https://plus.google.com/u/0/+VladimirPrus/posts/5spgjicc3fv

Hi Vladimir, I tried to take the poll, but I figured out that none of the options there reflects my opinion. Instead let me describe it here. I am a potential reviewer of many candidate libraries, yet I often decide not to participate, for various reasons. Let me list them here: 1. I have a lazy and "consumptionist" attitude. Boost is for free, so I would rather wait that someone does the job, and I just consume it. No-one can help here. This is only up to me. So I either don't try to make an effort (of reviewing) and if I do I am easily put off by any obstacles. I admire people here that you are willing to invest so much of your personal life into making Boost better. I guess this means you are decent men, driven by what is right rather than what is beneficial. Perhaps if there were some incentive, like being credited in the Acknowledgements section, that would make use of my vanity. 2. I am put off after reading the first pages of the documentation. Library authors, are focused on code and often do not pay much attention to the documentation. Even if they are forced to do it upon submission into Boost, my impression is that often they are only doing it because they are forced to, and they do not understand why. As a consequence, the documentation is there, it is structured, but has little value. The motivation section is there, but does not motivate me to anything. I start the review with an assumption that the author invented some "toy" that may be a cool exercise, but does not help solve any practical problem. When I see the documentation without a clear motivation (what REAL problem this library helps solve), I immediately conclude that this is a toy library. Of course, I might be wrong in my judgement, but the likelihood of me being right is so big that I am not willing to invest more time in it. Robert does a great job here with Boost Library Incubator, but if the author only learns that he has to write a motivation section it is not enough if he does not understand why it is important - he will write a bad motivation. Perhaps what would help here is additional (somewhat brutal) questions. "Your library is just useless toy! Can you convince me otherwise in 3min?". Or: "You probably do not know the basics of C++: exception safety, RAII, distinction into programmer errors and run-time contingency! Can you convince me otherwise in the Tutorial section?". 3. Sometimes I am too impatient to go through a full review. I have got some partial input, that I consider important, and I want to deliver it right now. I do not want to wait till I have gone through all the questions. I have a question to Robert now. In Boost Library Incubator, is there a way to submit a partial review: it is more than just a comment, but I still may be sending more information later. Can I do it in Boost Library Incubator? Or can I submit two reviews? Or update my first review later? 4. I am very reluctant to answer the final YES/NO question. How am I supposed to know if the library should be included into Boost or not. What is the criterion for inclusion? What is Boost supposed to be? Candidate libraries for standardization? Bug fixes and workarounds for broken compilers? Clever experiments? Anything that meets certain predefined set of criteria? Anything that is not niche (that we expect to be useful to many many people)? Anything that the people vote "YES" on? I know there is no consensus on it anymore in Boost. Or am I wrong? I hope this helps anything. Regards, &rzej

[Please do not mail me a copy of your followup] Andrzej Krzemienski spake the secret code thusly:

[...] "Your library is just useless toy! Can you convince me otherwise in 3min?".

+100 Just change "3 minutes" to "30 seconds" :-). -- "The Direct3D Graphics Pipeline" free book http://tinyurl.com/d3d-pipeline The Computer Graphics Museum http://computergraphicsmuseum.org The Terminals Wiki http://terminals.classiccmp.org Legalize Adulthood! (my blog) http://legalizeadulthood.wordpress.com

[Please do not mail me a copy of your followup] Vladimir Prus spake the secret code thusly:

Say, if I can made per-line comments on proposed library code, like gerrit does, it would be rather useful.

You can do this on github already. You can make comments on any line of any commit. So, if you want to give line-by-line code review feedback of a library and it's hosted on github, have at it. -- "The Direct3D Graphics Pipeline" free book http://tinyurl.com/d3d-pipeline The Computer Graphics Museum http://computergraphicsmuseum.org The Terminals Wiki http://terminals.classiccmp.org Legalize Adulthood! (my blog) http://legalizeadulthood.wordpress.com

On Nov 7, 2014, at 12:04 AM, Vladimir Prus wrote:

...

On 11/07/2014 04:06 AM, Richard wrote: [Please do not mail me a copy of your followup]

Vladimir Prus spake the secret code thusly:

...

Say, if I can made per-line comments on proposed library code, like gerrit does, it would be rather useful.

You can do this on github already.

You can make comments on any line of any commit.

Presumably that's why I've said, earlier:

In fact, maybe the best way to run a formal review (or informal review, whatever) is to post a link to github repository, where comments on the code can be made already, and issues created?

Comments and issues are important ways of providing feedback which haven't directly been part of Boost reviews before, but I don't think they replace the broader discussions which happen in traditional reviews. I think these channels may help authors refine their work more than they help review managers, but I could also see them joining the criteria managers may use (at their discretion) to decide whether to accept a library.

...

So, if you want to give line-by-line code review feedback of a library and it's hosted on github, have at it.

Not sure whether you agree to the quoted hypothesis or not.

-- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Vladimir Prus-3 wrote

it's just we see that formal reviews are not as well-attended as before, and one way to improve might be to make participation easier.

I've been concerned about the low attendance in the formal review process for years. (Is Boost Broken? BoostCon 2010?). The motivation behind the design of the incubator is to "make participation easier" by decoupling the preparation of the review from a specific 1-2 week time frame. It was also specifically designed to not alter the actual Boot Review process. So far, it has only garnered one "pre-review" so one could say it's a failure. But I'm not done yet. I'm very stubborn - I made 27 versions of the serialization library (with one formal review which rejected it. I'm not done yet here either. There wiil be incremental changes in the Boost Library Incubator implementation to encourage more reviews. The original question on this thread was really about considering a change in the methodology of the formal review process. This might be an interesting question, but it is totally orthogonal to anything in the Boost Incubator. The Boost Incubator doesn't attempt to change any boost policies - just make the agreed upon policies better. Narrowing the focus and scope in this way is very important. a) it keeps the incubator implementable b) It means that a failure in the incubator doesn't ripple over into boost policies itself. It just means that the incubator has to evolve. That is the incubator is dependent upon boost - but it will never be the other way around. c) It permits me to impose one persons (hopefully) logically consistent, sharply focused concept on the design and implementation of the incubator. The boost community and/or other programmers are then free to accept, reject or criticize it. This is a reflection of how boost works - and to some extent how C++ works. So anyone is free to criticize it, offer suggestions, explanations why it's not progressing more, etc..... But suggestions for improvement of the boost process belong in boost - not in the incubator. Yours truly, is but a humble servant of Boost. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Incubator-Status-Report-tp4668747p4... Sent from the Boost - Dev mailing list archive at Nabble.com.

Edward Diener-3 wrote

Other than lengthening the formal review process to encourage more people to participate I do not see any means to get people more interested in reviewing Boost libraries. As far as the incubator is concerned I feel it is a good idea but nobody is using it to comment on libraries.

As far as Boost reviews it appears that most programmers are afraid to even make comments about a potential library in which they may be interested. Maybe the specter of C++ experts scares them away. Maybe they feel that they might look foolish if they make a comment which is based on just a partial understanding of the library involved.

If you select the "Display Statistics" Button on the Safe Numerics and display the last 60 days of activity, you can see that the library page has 50 visits. This is not a huge number. A book on Amazon might sell 1000 copies and get a couple of reviews (most of whom are likely the author's relatives). So as the incubator becomes more a "go to" place to look for libraries, the question of small number of reviews would solve itself. (hopefully). And of course if one can make a review at the moment he's decided to use or discard the library, it's more likely that, being in a state of ecstasy or frustration, he'll display his feelings by making a review while the facts and emotion are fresh in his mind.

Finally there is a decided problem with the lack of people willing to be review managers for a library.

Again, if we had more "pre-reviews" getting a review manager would be a snap. a) a library with a large number of negative pre-reviews will likely not even be selected for review. b) a library with no reviews suggests that it's not getting enough usage to be useful so maybe it's not worth reviewing. b) a library with a large number of positive reviews - it's easy to be the review manager. c) for the rest - well, at least the manager knows what he's in for. That might make it easier. In short, I would hope if we can make the incubator a success, it will help with the shortage of review managers. If any library in the incubator ever gets enough reviews, and gets reviewed, and passes review, I intend to leave all the reviews on display indefinitely. In fact, I intend to allow anyone to post review in the future. Current boost libraries vary a lot in quality but our current setup doesn't make that visible. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Incubator-Status-Report-tp4668747p4... Sent from the Boost - Dev mailing list archive at Nabble.com.

Rob Stewart-6 wrote

When interviewing C++ developers, I find those using Boost libraries, at least beyond shared_ptr, are rare. The brand is known by relatively few, and it is used, to any significant extent, by fewer still. That implies the need to grow our ranks through some form of advertising.

To me this is a huge issue. I see huge opportunities for improvement in the standard of coding and software design of C++ software. I'm familiar with other programming systems and I found they all pale in comparison to the power of C++ in abstraction and development. C++ is not without it's problems however. Without into them, I can say that I see a huge need and opportunity for Boost to move beyond backfilling the standard library into the promotion/education/demonstration of how programming really should be. Rather than hacking together all sorts of stuff and adding a layer of tests to flush out the design problems, as has been done for the last 40 years, I want to encourage more intentional formal design - not just by experts but by "the rest of us". The incubator is much more than a common facade over a few libraries. It is meant to show how quality software should be built. Right now, it has only my own views on this - lol - but no one has criticized them. I've always felt that Boost was great - but could be a lot better. I want to promote a higher standard - especially in the area of documentation, design, usability, corrections, etc for boost and by implication the rest of the world. I am not modest. It's a work in progress - but I think I'm on the correct path. Anyone who shares this vision is free to get on board. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Incubator-Status-Report-tp4668747p4... Sent from the Boost - Dev mailing list archive at Nabble.com.

Edward Diener-3 wrote

Having worked for approximately 30 different companies in my career as largely a computer programming consultant I am well aware of many programming shops, even within major corporations, who have no clue about reusability of software.

There is absolutely nothing Boost can do for such places, because the general understanding of program creation is so low and in the hands of programming managers and their like who do not understand programming design in any way.

I have fought too many losing battles with companies for which I have consulted, trying to convince people whose programming talent is low, that using reusable libraries such as Boost will make it easier to accomplish their goals.

LOL - you're preaching to the choir here. But I don't think things are totally hopeless and I think Boost CAN improve the situation. I remember when STL became available. There was a lot of negative reaction due the to fact that it had a lot of unfamiliar concepts such as function objects, iterators, and others. But slowly it did get taken up. One reason for this success was the quality of design of STL (not perfect but as good as C++ permitted), and the quality of STL documents (SGI website, STL Reference, (Musser), and Scott Meyers Effective STL. To a small extent the same has happened with Boost and things will likely improve at least for those parts of Boost incorporated in the standard. Books like Boris Schaling's will also have a positive effect. In my view, the single most effective Boost could do is to raise the standards for documentation of Boost libraries and help library authors meet these standards. This is a primary focus of the Boost Library Incubator. There's one big problem however. There isn't a strong consensus on what high quality C++ library is. I've tried to make the case for my viewpoint in the incubator (Advice, Concepts) And I think this has helped some - but still there are lots of people who I haven't yet been able to sway to my point of view. This is a work in progress. TL;DR; For reference - I'll include a short summary of my views on this subject: a) All template parameters type requirements should be explicitly documented. b) The above preclude the usage of documentation tools - specifically DOxygen which cannot support the creation of documentation in accordance with a) above. c) All template parameters should be at compile time so that that the compiler will trap when a user attempts to use a type which does not meet the documented requirements. d) C++ does not currently support the above in the language itself. But this is no reason not to check the parameter types using Boost Concept Checking Library or other means. It's not a lot more complex than that - and would seem to me to be uncontroversial - but there has been a lot of resistance to this point of view. I'm still working on that. As an example, I will site the Boost Units library. Not that I'm not picking on this particular library, there are many examples in Boost, but this one is close to my heart. This is an incredible piece of work. Usage of this library would be hugely beneficial in many, many programs. But the documentation of this library makes it very, very hard to understand how to use it. A naive programmer cannot simple spend an hour looking over the documentation and get his own simple example working. He then moves on - for good reason. For Boost to continue forward - it has to appeal to the "rest of us". That means a) more libraries, b) of much higher quality, c) supporting more niches areas, d) which can be written by more people That is the motivation and purpose of the Boost Library Incubator. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Incubator-Status-Report-tp4668747p4... Sent from the Boost - Dev mailing list archive at Nabble.com.

Rob Stewart-6 wrote

...

b) The above preclude the usage of documentation tools - specifically DOxygen which cannot support the creation of documentation in accordance with a) above.

What's wrong with the tparam attribute?

I didn't know about this - I'll take a look at it. When I looked at DOxygen, I concluded that, though it might be possible, it wasn't easy to create a page describing a concept. Indeed, I've never seen DOxygen which included concept pages or description of template parameters. If you have information/experience with this, feel free to add that information to the page in the Incubator where I discuss my impressions of various documentation tools in the context of Boost quality library development.

...

c) All template parameters should be at compile time so that that the compiler will trap when a user attempts to use a type which does not meet the documented requirements.

I assume you meant to write that template parameters should be checked at compile time, in which case I agree. Unfortunately, the tools we have for that are awkward presently. We're awaiting concepts.

...

d) C++ does not currently support the above in the language itself. But this is no reason not to check the parameter types using Boost Concept Checking Library or other means.

When possible, I agree. Unfortunately, the use of BCCL can change the characteristics of a type such as making an otherwise trivially copyable type non-trivially copyable.

This is news to me. Assuming this is true - it's easy to use static assert to get the same effect. My point is - Don't wait for language support - start using what we already have.

...

For Boost to continue forward - it has to appeal to the "rest of us". That means a) more libraries, b) of much higher quality, c) supporting more niches areas, d) which can be written by more people

There is certainly room for the niche libraries you mention, since they won't be standardized.

I believe that the idea that the idea that every good library should be part of the standard is a bad idea. Basically it can't scale and is likely reached the end of the road. We've already made C++ so large (by requiring libraries) that we're down to 3 suppliers of C++ compilers. I don't see hope for new entrants - which we used to have. Coupling the language to libraries has a huge downside. Admittedly, accepting Boost libraries into the standard has been a huge boon to Boost. But let's not get too stuck on that. Use our credibility and imprimatur to fix the real problem - a world inundated with crappy, fragile, opaque software that is so bad people keep more of it.

To your point of libraries "for the rest of us", one way that Boost causes itself problems is by our dissatisfaction with simpler designs. We're enamored with more esoteric designs. The imposition of templates when polymorphism would suffice, even if suboptimal, turns off many, the STL notwithstanding. Perhaps we need to encourage both kinds of libraries.

I absolutely agree. I want to take this head on. a) encourage better documents. I believe that one reason we have over elaborate designs which lose sight of the ultimate purpose is that we don't insist on readable documents and clearly define, orthogonal, de-coupled concepts (not the C++ concepts - but in the real sense of "concept). b) we need to upgrade our deployment to permit subsets so that components can be dropped without a huge trauma. c) we need to permit the creation of better components which might compete with existing ones. We need to look more like silicon valley rather than downtown detroit.

The other difficulty is that many companies are pleased to use high quality, free libraries, like those from Boost,

Everyone likes free stuff

but are reluctant to permit sharing those created in-house.

Often because they don't want the world to see how crappy their code is. I've done work or a fair number of companies, and I never seen any code which would meet the admittedly low bar of the Boost Inclubator - much less for Boost itself. That's why most of are here - because it's a place where doing a good job is actually appreciated.

The result is that many potential additions to Boost and, ultimately, the Standard are excluded.

And I hope the incubator will be a place which can promote and enforce software quality even for C++ software which for one reason or another isn't not headed for the standard. There is lots of stuff that is really good - but wouldn't really fit in the standard. Boost Spirit? Serialization? I doubt it. Safe Numerics? I think this should be in standard 15 years ago - but it doesn't seem to create much interest. Looking forward - lets focus less on the standard and more on rolling back the tide of crappy software that we're drowning in. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Incubator-Status-Report-tp4668747p4... Sent from the Boost - Dev mailing list archive at Nabble.com.

Niall Douglas wrote

My vision for how to renovate Boost previously explained on this list is that we need ...

I think this deserves a thread of it's own. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Incubator-Status-Report-tp4668747p4... Sent from the Boost - Dev mailing list archive at Nabble.com.

On 11/10/2014 7:33 AM, Niall Douglas wrote:

On 8 Nov 2014 at 15:53, Edward Diener wrote:

...

...

When interviewing C++ developers, I find those using Boost libraries, at least beyond shared_ptr, are rare. The brand is known by relatively few, and it is used, to any significant extent, by fewer still. That implies the need to grow our ranks through some form of advertising.

Did anyone ever get promoted for jumping onto new language features before they are commonplace? I'd doubt it.

1) I did not write what you are responding to. Please quote correctly. 2) Many ( most ? ) Boost libraries are not about new language features. 3) I never realized that using a software library is all about getting promoted in some programming job.

...

I have never seen this. Good C++ programmers use Boost libraries when it saves them work because the libraries are high quality. Bad-mediocre programmers re-invent the wheel incessantly.

I strongly disagree with this. People, which programmers are usually as well, respond to incentives, that's all.

A top class C++ engineer sitting on the ISO committee may in fact *often* reinvent the wheel incessantly at work. If their corporate employer takes a minimum of three months for Legal to clear the use of any new version of an open source library and your work item requires you to deliver the solution inside two months, you follow your incentives and you go ahead and reinvent that wheel.

There is also the substantial problem still present at most employers that your engineering prowess is judged on lines written and JIRA issues closed. Reinventing the wheel will always generate more lines written and more JIRA issues for you to close. It therefore substantially increases the chance that your job role will be seen as vital to the company, and therefore someone else will get axed before you will.

You must remember that as with most non-consulting programming roles, your single highest priority is to retain your job at all costs. Your second highest prority is probably to keep your family happy by not getting dragged in for overtime constantly, and your third highest priority is to not hate your work too much, which means avoiding doing anything controversial or anything which might annoy anyone else and cause them to throw crap your way. Engineering quality come very far down the list of priorities for most programmers. And therefore, by implication, so does Boost - if anything, using Boost marks you as having a touch of zealousness, and therefore as a threat to the org which must be eliminated as soon as possible by anyone with "career aspirations".

I couldn't possibly state that any of the above comes from personal experience working in large corporate orgs :)

...

Having worked for approximately 30 different companies in my career as largely a computer programming consultant I am well aware of many programming shops, even within major corporations, who have no clue about reusability of software.

I think this is harsh. It's more they don't *care* about reusability. And why should you: reusability equals fewer jobs and higher risk of getting laid off. What you really actually want to write is code which works just about well enough to make your job mission critical, but not well enough they don't need you any more.

...

There is absolutely nothing Boost can do for such places, because the general understanding of program creation is so low and in the hands of programming managers and their like who do not understand programming design in any way.

It's more again that they don't care, or rather don't prioritise. Even if you yourself care, your line manager and their line manager worries about fighting for resources in the org and making sure that their team remains ranked high by management compared to other teams. They also have powerful incentives to not produce too excellent engineering. They do have strong incentives to be seen as excellent firefighters who can "save" a failing mission critical project. None of this implies good design from the outset. It's really all about throwing banana skins under feet, at least from the line managerial point of view, and wrapping good patches around terrible design.

...

I have fought too many losing battles with companies for which I have consulted, trying to convince people whose programming talent is low, that using reusable libraries such as Boost will make it easier to accomplish their goals. OTOH I have also worked for a number of smart companies which will use Boost libraries, as well as other reliable, specific programming libraries which exist, to increase their productivity.

Using Boost will substantially raise your recruitment costs. Right now my current client who uses Boost and the C++ 11 STL extensively is trying to hire more engineers willing to relocate to their HQ and we've already dumbed down the job description once, and we'll probably have to drop any mention of the STL or Boost and any mention of unit testing or multithreading next because we are seeing *zero* applications.

I get it. Your view is the mercenary one where no one in corporate programming cares about anything but making money, job security, and getting ahead in whatever way possible. Bravo ! But in that view also Boost has no business trying to appeal to programmers in the corporate world by dumbing down its software. I do agree with Robert Ramey that better documentation is always an admirable goal for library developers, since understanding what a library offers is necessary for deciding if it is of any use.

On November 10, 2014 3:09:48 PM EST, Niall Douglas wrote: [snip dark commentary on programming] I'm glad I've not had much experience in the programming world you describe our have been too dense to recognize it. For me, finding a library that solves my problems is valuable. Documentation is a big part of that. Usability and packaging are important, but I can deal with issues in those areas when the value is high enough. I just finished writing a sizable build system wrapper in Perl, a language I dust off once every couple of years. Google found the information I needed, but it wasn't always easy. The official docs assume comfort with all of the magic variables and subtleties of the language, which is worse than with C++ to me. That means the docs are best for experts and off-putting to the inexperienced just trying to make something work. There were, fortunately, other sites that explained things clearly enough to help me. Boost is in the same boat. The docs assume domain knowledge in many cases, and generally assume language expertise. Anyone lacking that background must rely on other sites to fill in the gap, of which there are fewer than for Perl. Perhaps encouraging reviews from those without domain and language expertise would be smart. That would encourage documentation that helps to build domain knowledge, even if only through links, and doesn't presume language expertise. Documentation that caters to Joe Programmer should increase the odds that search engines find Boost libraries, and that such programmers pursue using them once found. ___ Rob (Sent from my portable computation engine)

On 11/11/2014 05:40 PM, Niall Douglas wrote:

I've noticed us old timers don't immediately jump into coding prototypes to test ideas as much as younger engineers which I assume is a Silicon Valley thing. They literally try to hack together something which might work using whatever libraries pop out from the first page of google results. This works well with webby and interpreted languages as you don't really need a build system.

In theory. In practice, there's Grunt and there's Gulp, and there's two competing module systems, and there's minification and concatenation and there's coffeescript and CSS preprocessors, so in the end, web projects have quite non-trivial build systems. -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com