Boost Users :
Subject: Re: [Boost-users] what happens between "fixed in development" and "available in release"?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-03-20 08:18:13
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
> 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
> 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
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
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net