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

Subject: Re: [boost] RFC: Separating Boost.Python from Boost
From: Rob Stewart (rob.stewart_at_[hidden])
Date: 2015-05-29 19:41:18

On May 29, 2015 6:38:59 PM EDT, Stefan Seefeld <stefan_at_[hidden]> wrote:
> On 29/05/15 06:32 PM, Andrey Semashev wrote:
> > On Friday 29 May 2015 18:08:26 Stefan Seefeld wrote:
> >> On 29/05/15 06:03 PM, Rob Stewart wrote:
> >>> If your changes have the effect of removing Boost.Python from
> Boost
> >>> releases, then they have broader implications than the convenience
> >>> or wishes of the maintainers.
> >> Sure, I didn't say they don't have implications for anyone. (I
> wouldn't
> >> have started the discussion if they hadn't.)
> >> However, only the people doing the actual work can chose where they
> put
> >> their effort. So you shouldn't discount them when talking about
> >> decisions to be made (or not).

If your decision affects Boost, then I should indeed speak up.

> > If your plan is to remove support for building your library as a
> part of 
> > monolithic Boost then, at this point, this would basically mean
> removing the 
> > library from Boost distribution. I'm sure this would be a painful
> change for 
> > users, so forking the library may be more preferable in this case.
> 
> Right, understood. The problem I expect is that, as long as both modes
> are enabled, nothing will ever change, so a little bit of coercion is
> a Good Thing. ;-)

>From the tone and direction of your posts, you have decided that Boost will move away from monolithic releases and that sooner is better than later. There are many interested in getting away from monolithic releases, but not all are convinced. The onus, then, is on those that want the change to create the infrastructure to produce user-directed distributions. Once those are available, user choices should indicate if such distributions are useful and wanted. If that's the case, Boost can plan a transition from monolithic releases.

> The ultimate goal I have is for Boost to become an umbrella
> organization
> of individual projects (typically one per library), which all prepare
> their releases independently and autonomously. Some common
> infrastructure would allow to validate their inter-operability, and
> thus
> make it easier to establish a "boost distribution", where users can
> choose the components from they really need.
> 
> Of course that's not a decision I (or anyone else for that matter) can
> take on alone. It's something to enable in each individual library,
> though, and eventually to agree upon as a community.

I take your plan to be to remake Boost according to your wishes, dragging the community along for the ride. That disturbs me.

If I've read too much into your posts, please clarify what I've misunderstood.

___
Rob

(Sent from my portable computation engine)