Niall Douglas wrote
I always felt the Community Maintenance Team should have been configured as a bounty based system. If someone needs an unmaintained library to be maintained in some way, then they stump up a bounty for it. Note by unmaintained I would cast the net to include libraries with maintainers, though in that case the maintainer gets a veto. I also think the maintainer should get first dibs to the bounty too, they already have thankless jobs.
This could be seen as creating incentives to not maintain libraries. I'm happy with that - software is expensive. I wouldn't go so far as holding users to ransom for fixes on payment though.
I've never been convinced of the Community Maintenance Team approach. I believe that the incentives are all wrong to make it effective. I will be offering an alternative aproach. A glimpse of this alternative can be seen looking at the library page for Safe Numeric in the incubator. But let's not discuss this here - it's not relevant to the question at hand. As a reminder - I maintain that the merge from develop into master is a trivial operation. If anyone is finding this not to be the case, they are not doing right.
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.
With respect Robert, Serialization has nothing like the amount of code intricately dependent on it behaving exactly in some way, including in ways it was broken in the past.
I doubt this - but it's irrellevant. My proposition is that merging from development to master is trivial operation. If it isn't for you, then you're doing something wrong. The difficulties or peculiarities of any particular library are irrelevant to my view and my argument. Thread offers no less than four versions .... ... snip... all the difficulties about working with boost thread, yada, yada, yada...
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.
master branch is special with Boost though. It's not just the "unit tests pass here" branch, but also the branch used to generate Boost release.
LOL - one might say it's special. But merging one's current develop branch into the master is a trivial operation. If it's not then he's doing wrong. Or possibly when he says "merging the develop branch" into the "master" he's referring to other stuff like debugging code while it's in develop or who know what else. This other stuff has nothing to do with merging the develop branch into the master branch.
That means writing code and merging is 50% of the effort of merging develop to master.
LOL - we're not communicating. merging develop into master should require absolutely no coding. At the end of the operation for the library in question the code in the master should be bit for bit identical to code in the develop branch - that is all that the merge does. (could be a slight simplification if multiple authors are working on the same library and the authors are conflicting - but would be an extremely rare case here so I'm ignoring it). I finished AFIO v1.3 some weeks ago, but I haven't merged from develop to master yet despite all unit tests being green apart from Mingw32, which I am going to drop support for (Mingw-w64 works, Mingw32 is just horribly broken). That's because for a merge to release branch I have yet to do: 1. Update documentation to reflect the new facilities, and indeed your Incubator review where I believe I have addressed the majority of your concerns at least partially. I've been at this for nearly three weeks now. You only get so much time outside of work. 2. Rewrite the design rationale as it is now quite stale given my recent empirical testing findings. 3. Add unit test targets for Android 5.0 which now supports C++ 11. Fix any failures. 4. Add more tests to improve line coverage as I know it's dipped below 90%. 5. Run compilation time benchmarks on all platforms. Fix any regressions. You might think this easy, but AFIO has about twenty different build configurations now. 6. Run performance benchmarks on all platforms. Fix any regressions.
So actually, you're not done developing. It's not the merge to master which is holding you up, it's finishing the development on the develop branch. If Boost were to release the current master friday - things would be as they were - your changes just would appear later in the next release. So if you that friday is "too soon" what you're really asking is that users of other libraries be denied the upgrades they've be waiting for so you you can ... deliver your stuff later? Where is the logic in that? If your not ready - let everyone else deliver. If you are then you've got no problem.
You just develop at your own pace and merge to master when you're done.
I had been hoping to merge to master for end of January, it's currently looking like mid-February. water for my mill
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.
I think a huge amount depends on how legacy your codebase is and how tightly other people's code depends on yours being exactly as before.
if you're not changing the library interface then there is no problem. Including/not including one's changes won't make a difference. If you're changing an existing interface then we have a whole new problem. This new problem won't be made better or worse by delaying a release to meet the schedule/problems of a specific library.
I'll put it another way: QNX and Microsoft expend enormous resources making sure all future versions of their software have identical behaviour to before when in some form of compatibility mode. There is a big customer demand for that sort of "reliability", and people willing to pay serious bucks for it.
LOL - well boost customers haven't seem willing - so far at least. Maybe that can change but for now that's the way it is.
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 am not a fan of this model. The Web 2.0 culture does this a lot, but they provide services which can and are remotely updated if showstoppers turn up. When you ship a library on the other hand, that release is probably going to turn into stone in someone else's code.
This is not the web 2.0 model which is basically, just ship it and let the customers test it, when they find problems we'll just ship them a "service pack". This is entirely different. This is:code in the master has been test to the point where it has no known bugs. It is deemed ready to be used by users. This is true irregardless of whether it has been shipped as Boost 1.xx. Any code which does not meet this standard can be found on the develop or some other branch. It's really just that simple. 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.