Nicola Musatti wrote:
Jeff Garland wrote: [...]
Most of these libraries should be in 1.35, which will hopefully be released 'quickly'. By quickly, I mean ~1.5 months...which means a beta release 1 month after 1.34. Yep, that's right, I think we need to set some very hard goals to re-energize the boost release process. After the '1.34 experience' I've become even more of an advocate a hard line release approach. That is, we should set the deadline and only accept code that can make it in the release timeframe -- if it's not ready then we take it out and let it slide to the next release.
I wholeheartedly agree! On the other hand for this to happen it is necessary to stop addition of new libraries now. Are there any approved libraries that aren't in CVS yet? If there are maybe they should be allowed a time slot for new additions, before going into a bug fix only mode.
property tree, bimap, accumulators at least. But yes, we would need to specify a cutoff for addition to make the schedule. However, with more frequent releases it's not as big a deal if something slips.
To minimize risk of delay and release the pent-up backlog of new libraries I believe we should hold all existing 1.34 libs constant and only add in new libraries that are basically ready to go now. I've actually done an 'alpha test' of this approach and it looks like this will work -- that is, most of the unreleased libraries can be build against a 1.34 core without dependencies on changes to existing libraries (there are a few minor exceptions). Behind the scenes I've been encouraging developers of new libs to get their code into CVS so we will be ready to begin the nano-second after 1.34 ships.
Are you implying that you'd set aside all changes to existing libraries that are already in HEAD? Isn't this a bit tough on library authors that put in up to a year and a half to improve their libraries?
Yep, but I suspect many of the really critical fixes got moved into 1.34. If there's someone with a really important exception it could be discussed, but it would have to be really good.
Now, I realize that we have a plan to switch to subversion and have a new process that has been developed by Beman, etc. But it's my view that we should pursue a CVS based approach because it requires zero time to implement. In the meantime the subversion conversion can proceed in parallel. When everything is 100% ready to go we switch. My worry is that the conversion of regression testing, developers, and all other release process changes will wind up delaying 1.35 by several months. Of course, if my pessimism is misplaced then we can switch to subversion for the 1.35 release. Nothing will have been lost because we will have been testing new libs for 1.35 anyway.
Are there tools to keep Subversion and CVS repositories synchronized? If that's the case the adaptation of the infrastructure to Subversion could take place in a development branch while your plan is carried out.
Don't know, but I'm sure the infrastructure development can be done in parallel with just a little thought.
I believe this is urgent because a major backlog of unreleased Boost code has now developed. The asio review was 1.5 years ago -- it's hard to fathom that it's not in a release yet. It's simply not acceptable to wait even 3 months more to get asio and other 'new' libs into a boost release. And besides, asio and the libs above are really just the short list: there's xpressive, GIL, bimap, accumulators, function types, and units that have been accepted now -- huge and important libraries. And it's not stopping, there's a review backlog, a pile of SoC projects, etc. We have to dramatically shorten the release cycle to get these libraries out into a release.
I believe there are to sides to this: one is to come out with 1.35 as fast as possible to make up for lost time, the other is to ensure that such delays do not happen again. In this respect I'm afraid that Beman's approach shares with the current one too much reliance on self discipline and team cohesion.
Actually, I think Beman's new approach is much closer in philosophy to what I'm suggesting. As I recall in provides for a small window to fix regressions after which breaking changes will be reverted. It's ultimate goal is to keep the HEAD much closer to release at all times. Still, it is untested so we don't know how it will really work yet.
Boost is too large and too intertwined to rely so much on self discipline and team cohesion simply is not there, apart possibly among a small number of veteran core developers.
Actually I think the main thing is that Boost is getting large enough now that there's almost always something being changed.
Witness for instance how many were taken by surprise by the switch to BBv2.
I don't want to dwell on BBv2, but after doing several similar conversions on large projects I was afraid it would be much harder than expected -- it's extremely hard to even make a list of all the things to do let alone what will go wrong. And when something goes wrong progress bogs down. I fear the same thing with subversion conversion. On it's face it should be easy, but there's alot of people, tools, and small non-obvious dependencies on CVS. I haven't even seen a list of all the scripts, web pages, processes, etc that need to changed before the changeover can be completed-- so I'm afraid we don't fully understand the impacts. Jeff