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-tp4671426p4... Sent from the Boost - Dev mailing list archive at Nabble.com.