Re: [boost] Release sponsorship (was: Re: Boost 1.58 schedule available?)

Subject: Re: [boost] Release sponsorship (was: Re: Boost 1.58 schedule available?)
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-01-22 12:58:16

Niall Douglas wrote
> On 21 Jan 2015 at 15:23, Robert Ramey wrote:
> 
>> Maybe it's time for some new ideas? Perhaps we can create a "Release
>> Sponsorship" program whereby a company which really believes needs the
>> updated "integrated" release can sponsor it with a cash contribution. 
>> The
>> release would carry naming rights so a company with name like "survey
>> monkey" could call it the "monkey" release with a link to it's website. 
>> Bidding would start at $1000 with 50% going into the Boost General fund
>> and %50 going into the release manager's general fund. 
>>
>> Certainly if having the newest integrated release isn't worth $1000 to
>> any company on the whole planet,  it's not worth a release manager's time
>> to deal with all the hassle making and distributing a new release. 
> 
> You probably were being tongue in cheek Robert, but if not then this 
> might be the second time we are in complete agreement this week! Next 
> thing might be pigs flying!

I'm very serious about addressing this particular suggestion and about
evolving the boost revenue (or lack there of) model.  I'm aware that
this is a very difficult problem that won't be solved with just an idea.

> Regarding releases, they are highly disruptive to the develop branch 
> as basically one has to down tools on feature work and spend an age 
> iterating fixing up master branch such that all the other master 
> branches in all the other submodules play well together on all 
> supported platforms. 
> 
> For quickly moving libraries such as Thread, I 
> can see four weeks per release being lost. Increasing release 
> frequency increases that cost substantially.

If this is the case, then something is not right and needs to be
addressed.  It's hard for me to comment on your particular case without
spending a lot of time looking at the details,  but I can speak from
the experience of maintaining the serialization library over many years
through several different Source Control systems and several different
workflows.  My current view is that our issues with with these things
are now largely solved and we are in a good position to take boost
to the next level - whatever that might.

I work on my own schedule. I work on my development branch and
test there. When it's passing ALL tests, I merge into master.  the
master branch of the serialization library is always ready for release
as far as I know.  That it is a strict improvement over the previous
version of the master branch and has no known regressions.  The
timing of the "official boost release" is irrelevant to me.  I think that
anyone who has to know the release date is not doing things the
way I'm doing and that they should start doing it that way.

> Hence I do wish there was a facility for sponsors to sponsor a merge 
> of develop to master. If this had been the case for Boost.Test, would 
> its develop branch have remained unmerged for so many years? No, I 
> think someone would have done the merge if $5000 were on the table 
> for it.

Again, if merging from develop to release is a big problem, someone is
doing something wrong.  It should be almost trivial.  As such
it doesn't need any financial incentive.  In fact, financial incentive would
be the worst thing - it would be encouraging the continuance of a 
some sort of broken workflow.

> Also, I think there is some scope for some libraries to be released 
> quicker than Boost central. One could target the last released major 
> Boost release - now we have git submodules, one simply swaps out the 
> module and rebuilds the headers and docs.

This is a whole other subject and a very interesting one.  The future
model of boost will be not include a monolithic boost distribution with
a specified release date.  I will talk about this in more detail at boostCon
comedy club talks if my session proposal(s) is/are accepted.  But
in any case, it's orthogonal and off topic for the current problem.

> Unofficially in AFIO I have been supporting combining it with any 
> Boost release since the first modularised one. It has macro logic 
> which adjusts what it does according to the Boost version it detects. 
> I may drop that support at some point, but it's food for thought.

This is the correct procedure.  Hopefully it shouldn't be too onerous.
If it is - then there's another problem - breaking interface changes - 
which should occur relatively infrequently.

Also the same approach is used by the serialization library to maintain
computability with C++03 and C++11+ .  If there are facitlites in C++11
which improve the library implementation, these are condition on boost
config macros.  This turns out not to be all the problematic.  Of course
if one were to write the serialization library from scratch today, one
would not do this - but given the history and current status, I only
make changes to C++11 where some benefit obtains.

Personally I think the problems of "maintenance" are over stated. If 
maintaining (as opposed to adding features) is a lot of work, one needs
to step back and look at what he's doing wrong and think about how
to change it.

One final thought.  How about using the "surprise release" © model? 
This one is someone looks at all the test matrices for all the libraries. 
When they (almost) all look good.  The release is announced and the
release branch is closed to updates except for any pending errors.  No
new features, etc.  The the release is no work for developers at all!!!!
I know this sounds like I'm trying to be funny, but I consider this a
serious proposal.

I'm cursed with the ability to be funny when I'm not trying to be funny and
not funny when I'm trying to be funny.  funny how that works.

Robert Ramey

--
View this message in context: http://boost.2283326.n4.nabble.com/Boost-1-58-schedule-available-tp4671426p4671527.html
Sent from the Boost - Dev mailing list archive at Nabble.com.