Re: [boost] Idea: Boost Software Foundation?

Subject: Re: [boost] Idea: Boost Software Foundation?
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2009-11-25 12:14:31

On Wed, Nov 25, 2009 at 11:54 PM, Matt Chambers
<matthew.chambers_at_[hidden]> 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