Dean Michael Berris wrote:
1. Move Boost away from Subversion and let's use Git instead -- have each library be a separate Git repository, follow the model that Qt and the Linux follow, and have the maintainers develop their libraries at their own pace. Release managers then pull from the different repositories and work along with a team to stabilize a release that is supported as the de-facto Boost release.
So, instead of having each maintainer merge/push his changes to the release branch when he feels like that, you suggest that release managers ask maintainers of 70 (or is that 100 already) libraries what revision can be pulled to the release? That seems like create scalability problems on its own.
3. Set up a community process for choosing which libraries make it into the Boost distribution, which ones are dropped, whether there are multiple Boost distributions and/or mixes, etc.
4. Change the review process instead from a submission->review->inclusion process that's rigidly scheduled to one that is less rigid and is more fluid.
I would suggest you post separately about those proposals. I think that the current review process is actually good. It does not prevent anybody from using a proposed library in practice and provide real-world feedback. However, it encourages relatively deep look -- something that might not happen during production use. - Volodya