On 20 Mar 2015 at 8:43, Thomas wrote:
I do this independent of the release schedule and do it is "smallish" chunks. This generally works pretty well and the serialization library on the master is of the state "no known fixable bugs". It does suck a lot of CPU time but that's free for me now. The problem comes when something "breaks". I might forget how to do something, the build system might have evolved, etc. Then I have to call some mental subroutine which takes a lot of time to get back on track. The risk of this happening dissuades me from doing this procedure more often. In this particular case, he release came up in the middle of my cycle.
I am just a boost user, not developer, and don't follow this list closely. Here are my 2 cents, I hope they are not completely off:
By sheer good fortune myself and Robert are the leads of the two most articulated schools of thought on the future of Boost. We disagree, though less than in the past. I think C++ Now may see us move closer again.
What about making an upcoming release, e.g. 1.59, a "bug-fix" release only with the goal that all (or almost all) open issues get merged to master? No new features get added. If a library is stable (i.e. no open issues) leave it as it is (freeze it) and communicate that to other maintainers, so they can rely on a given version. Same for boost build and other tools, provide reference versions to rely on, no extensions. Give maintainers the time to get their issues fixed, do thorough testing etc. - if it takes half a year or longer, so it be, fine.
As user I too find it increasingly difficult to overview the status and reliability of boost versions, and switching to a new release can make matters worse (for me as user) then sticking to a "working" previous release. On the other hand I think that I can understand the tremendous amount of effort and commitment required from library maintainers. And yes I know that things can break so unexpectedly and distract for ages from main aims (last time here: a VS extension installed broke the default configurations set by boost build, and that did take us a lot of time). So as user I feel the responsibility to not expect miracles or unrealistic things from maintainers.
Note that my proposal aims at helping both users and maintainers: The former to get a hopefully stable release, and the latter to give them the time needed to make their developments and testing, without everything else in boost changing all the time.
I'll answer this from my perspective on this. Robert may do so from his perspective. Since the economic crash around 2008-2009, commercially sponsored work on Boost has enormously dried up which forced some of the big names to leave for greener pastures (e.g. Boost Consulting wound up), plus we got hit with a double whammy of the C++ 11 STL providing much of Boost, thus eliminating the commercial need to sponsor Boost specifically fixes in Boost. I have managed to make an hourly paid living this past year from some very limited Boost related commercial sponsorship, but just recently they decided that C++ takes too long and are rewriting everything into Rust, so I suspect I'll have to leave Boost for greener pastures myself in six months or so. Anyway, from my perspective the big problem is funding, or lack thereof. It takes a lot of time and effort to fix bugs, and very few maintainers want to exchange their unpaid family time for fixing bugs when they could be doing interesting stuff instead. Don't get me wrong, I think the community has done a lousy job relative to other open source communities on the business side of things on constantly lobbying for and funnelling monies into Boost - we only gained a Donate facility last year, and it was I who made that happen, and it tooks months of effort. I also think we do a lousy job of creating incentives (Robert would call it blackmail) for commercial sponsorship of older libraries by routinely kicking anything not maintained out of the main distro so we regain a lean, slim and tightly focused Boost. I personally am aiming to fork Boost into a C++ 11 only 2.0, and indeed this C++ Now I'll present on tooling to help with that. Myself and Robert do agree though that users don't pay their fair share. They get high quality libraries, but don't pay a commensurate amount for that. Equally, many of them would *like* to pay for it, in particular they would *love* to pay for timely bug fixes. The Steering Committee has not smiled on those arguments though. And without community consensus, it's tough to create movement. I might add that Robert has his incubator http://rrsd.com/blincubator.com/ where I think he has a bug bounty system configured? I personally think the bug bounty system needs a monthly emailed scoreboard, with escrow for the bounties. Again though, that would need community consensus to make happen. There is a strong antipathy against making Boost into a viable business. Stemming from its origins, it's supposed to be about the pet "hero" library project, not making a living. Robert is speaking at C++ Now about the future of Boost, and I'll be there too. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/