Re: [Boost-users] what happens between "fixed in development" and "available in release"?

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 
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/