On Wed, Nov 25, 2009 at 11:54 PM, Matt Chambers <matthew.chambers@vanderbilt.edu> wrote:
Dean Michael Berris wrote:
1. As a project, Boost and Apache try to (and I'd like to say both do) deliver high quality open source components under a liberal and commercially friendly license. Boost has many sub-projects that are worth naming like Boost.Build, (Boost.?)Quickbook, BCP, and Boost.Jam (although a little stagnant IIRC). Maybe treating other libraries as sub-projects that have a publicly-accessible and easily "forkable" repository would be a good thing. Git and Github come to mind.
2. As a software distribution, Apache has decentralized the release management of the libraries and software projects under its umbrella. This means sub-projects can depend on specific version releases of other sub-projects instead of making sure that there's only one release that bundles everything together.
If you want to compare with Apache, the Boost libraries are akin to the Apache Portable Runtime, not the Apache project as a whole (which is far more application-oriented than library-oriented). So it's not clear to me why you would want to split up libraries like Apache splits up applications. Sure, the Boost scope is bigger than APR, but not terribly so. I think if the libraries were split up as separate releases, that would shift the burden of synchronizing them to the library users, which seems like a very bad idea to me.
But you already do this when you're using multiple libraries anyway right? I guess the monolithic "single release" can still be pulled from different sub-projects like how Boost.Spirit is developed in Sourceforge then brought into trunk when it's stable enough to be part of the daily (?) test cycles. This way you the user can have a choice of using either the latest Spirit with an older Boost release, or the latest Asio release with the latest Boost release without using the "pre-bundled" Asio or Spirit that do come with the monolithic Boost release. There could be an integration phase, where a monolithic Boost release can pull the latest release among all the sub-project libraries and then make changes so that things don't break when users do choose to use the single monolithic release. This can be a community effort, meaning anybody (not a maintainer of the library being brought into the monolithic core) can make sure that the releasable version of Boost that people can download as a single bundle will work "out of the box". Then these changes can be submitted "upstream" into the sub-projects. This is how Linux works with distributed development repositories, where anyone can submit patches upstream to be part of a release that Linus "sanctions" (with the appropriate copyright attributions) or release their own version of Linux with their own changes. I can definitely imagine a git repository that BoostPro manages, one that Spirit publishes, an Asio git repository, <insert subproject git repository here>, and a "canonical" Boost git repository that pulls from the many different git repositories, stabilizes the "trunk" (AKA "master") and from which every other subproject will pull from. That said, anybody then can make a fork of the Boost git repository or any other subproject repository, make their local changes, and then request that some patches from your local repository be pulled by the project or submit patches to the maintainer of the repository you forked from. You can publish your own version of Boost but not call it an official Boost release while you're at it too.
It would make it easier in some cases to adopt a single library from Boost while leaving the others, but then trying to add more libraries begins the synchronization issue (e.g. some user has been using a recent version of library A; they want to start using library B, but library B's current release depends on an older version of library A, while the user depends on the recent version of A).
Which is where the community effort can come in. If you want to be part of the development for example of Boost.Serialization, then you fork the Boost.Serialization repository (assumes that we're using git on github), make your changes to your own repository, and then ask the maintainer of Boost.Serialization to pull from your fork. If you want to be part of the community effort to release a monolithic Boost release, then a release manager can take the latest stable release (or master, depending on the policy/strategy) of the subprojects and then integrate them into a single repository from where you can fork from and help stabilize the implementation, then ask for a pull from your repository be done. If someone would like to maintain for example a Boost 1.41.x line and take the effort to maintain a git repository that supports the 1.41.x release, then it should be entirely possible to do so by allowing sub-projects to evolve outside the monolithic Boost release on their own. Then it can be a community effort to allow submissions in a fashion that is still controlled/managed by the maintainer (the maintainer can choose to not pull from a fork). Now the foundation comes in to fund the operational expenses of paying a release manager for the time he spends working on release management, for project managers that track the progress of either individual projects/sub-projects, for publishing/hosting the website and the issue tracking system, and for the maintenance and operation of build/testing machines. All the coding is done by the developer community in an open fashion. Here you get: * A monolithic Boost release still with its own development/release schedule * Multiple subprojects that are encouraged to grow and evolve outside of the monolithic Boost release * An "organized" fashion for letting community contribution easier I hope this helps and makes sense. -- Dean Michael Berris blog.cplusplus-soup.com | twitter.com/mikhailberis linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com