Re: [boost] RFC: Separating Boost.Python from Boost

Subject: Re: [boost] RFC: Separating Boost.Python from Boost
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2015-05-31 00:14:57

On Fri, May 29, 2015 at 11:31 AM, Stefan Seefeld <stefan_at_[hidden]>
wrote:

> as I have mentioned here before, I would very much like to continue the
> modularization effort, by fully separating the Boost.Python project from
> the rest of Boost.
> For avoidance of doubt: my intent is not to remove Boost.Python out of
> the Boost organization. Rather, I would like to separate the build and
> release processes.
> For the sake of keeping the discussion focused, I would like to avoid
> getting into too many (technical) details (there already is a related
> discussion on the Boost.Build list).
> Rather, I would like to know whether people here (and Boost.Python users
> in particular) have any particular thoughts about this proposal. Any
> strong reasons not to move forward with this ? Things to consider while
> doing it ? Etc.
>
> (My hope is that if the operation succeeds, other Boost libraries may
> want to do the same, which would help Boost in the long term to become
> more manageable.)
>

In summary..

As the author of the only Boost library that is both independently modular
and at the same time part of Boost monolithic I'm not entirely opposed to
the concept of making libraries modular. I do have reservations, as others
have mentioned, with removing libraries from the monolithic release. I
prefer the route of allowing the modular use of the libraries but keeping
the "comprehensive" release (note my avoidance of monolithic).

In detail.. And with the various hats I wear in Boost..

As a library author I would like to:

a) Continue the development of my library as an independent entity as it
makes development and testing easier and more predictable.

b) Continue to take advantage of the distribution of my library as part of
the "comprehensive" Boost release. In my opinion such distribution hoists
the library into a position of being more likely to be used than an
independent decoupled release.

c) I would like to allow users of the library the option of using updated
versions of the library independent of the "comprehensive" Boost release
cycle.

d) I would like to continue to allow users the option of independently
using my library.

e) I would like to continue to have my library tested as part of an
integrated and quality tested Boost release.

f) I would like to have continuous testing of my library in as many
platforms as possible.

As a user of multiple Boost libraries I would like to:

a) Continue to have the option to recommend and get clearance on a
comprehensive Boost release for projects. As it is some times easier to get
such approval for the whole as opposed to the parts.

b) Continue to have the ability to recommend, get clearance, and use
individual modular Boost libraries as needed for individual projects. As it
is some times easier to get such approval on a smaller subset of libraries
than the whole of Boost. Note, I said continue because I already do this
with one of my projects with the "modular.jam" Boost Build extension.

As Testing Manager, and Release Team member, I would like to:

a) Continue to provide a comprehensive set of testing results for all
accepted Boost libraries. So that I can monitor the release state of the
comprehensive Boost release.

b) I would like to extend testing to include cloud/distributed continuous
testing of all accepted Boost libraries. And this aspect is really only
possible by testing modular libraries instead of a monolithic release
because of resource constraints (i.e. as Travis-CI and others are time
limited resources).

c) I would like to have a fully integrated comprehensive and packaged Boost
release continuously tested. So that doing Boost releases is a low cost
endeavor.

Definition..

What is this "comprehensive" Boost release that I keep mentioning? It's a
release that packages a fully tested set of modular Boost libraries that
has been tested to guarantee (within the obvious uncertainties) correct
functionality of those libraries and their dependencies. But it is not a
release that requires the use of the libraries as a monolithic single
package.

In conclusion..

I have the feeling that some of your goals intersect with mine. But I also
suspect some of your goals will collide with mine. But I thought I'd
mention what my position is since you asked for feedback on your efforts.

-- 
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
-- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail