On Tue, Dec 28, 2010 at 4:05 AM, Vladimir Prus <vladimir@codesourcery.com> wrote:
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.
Instead of looking at it in a binary either-or way, look at it in a different way. Maintainers get to develop the libraries at their own pace, allowing every library to cultivate a community of sorts of users and developers. I can totally see for example libraries like Spirit to grow and maintain its own community outside just one Boost community, and release versions of Spirit at the pace that that community likes. Of course then Spirit will have its dependencies on libraries like Proto and MPL, each of which can release versions on which Spirit can explicitly depend on. What this allows is for someone to maintain a globbing together of the requisite Boost libraries that deal exclusively for example with template metaprogramming (maybe Boost.Meta) that packages different versions of these libraries into a single distribution that is maintained by people that aren't necessarily part of the different projects. Then you can imagine a Boost distribution that just deals with things like ranges and algorithms that deal with ranges. Then there's might be a Boost distribution that deals with network stuff, etc. -- this allows Boost to grow in a scalable manner, and have the development of each library scale according to the communities that get built around these libraries. In the end, what you have are multiple Boost libraries developed in an optimal manner according to each one's communities, and Boost distributions that are built up from publicly released component Boost libraries. Think of how Linux distributions work -- each piece of the project is separate and there are people that work on just bringing together these things into a single coherent packaging. This is the way I'd like to think about making the Boost development effort more scalable. Instead of building just one Boost distribution, you can build many that contain different libraries.
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.
Sure, that's the plan -- I'd really write up a proposal that has more detail and concrete steps to take. What I wrote earlier was a high level view of the plan, which until now is still brewing in my head. ;) About the review process, the problem with the time limit that I see is the amount of work required to throughly look at a library usually doesn't fit in one week. And then the really deeper looks require quite a bit of discussion to clarify points and make sure that the reviewer and the library author(s) get to respond to questions and/or gather feedback regarding the implementation. By making the review process more of a collaborative development process instead of an "I'm finished, is it good enough?" thing, you can involve more people and encourage community building around your library. Having an incubation project, like the Sandbox, and providing a means of continuously improving and developing a library -- there's already a number of libraries in the UnderConstruction wiki page which may be wanting some love -- and encouraging people to work together to make the libraries actually get up to a point that would be deemed "Boost ready" should be better than reserving judgment on whether a library should be accepted in Boost in a week's (or two weeks) worth of reviews. Also, making the decision of whether a library should be accepted in Boost should more or less just be a matter of a vote, because if you really felt differently about how a certain library should get developed or if you want to actually influence the development of a library, it's all just a matter of forking the repository, making your changes, submitting your changes "upstream" and letting the community decide whether that change is worth taking in. This means more collaboration yielding libraries that the community of developers and users would really want to have, rather than building a library for a long time "alone" and then hoping that in the 1/2 weeks that your library is under review that people will actually care about it. I should really write all this down into an actionable proposal. ;) HTH -- Dean Michael Berris about.me/deanberris