[C++-sig] [Boost.Python v3] Planning and Logistics

[Jim Bosch]

In the interest of keeping this discussion easy-to-follow, I'm going to 
reply to Dave's email twice, with new subjects - I'll stick to questions 
about logistics in this email, and talk about features and scope in another.

In summary, I'm getting the sense that a branch in the mainline (not 
sandbox) Boost SVN is the way to go.  I imagine most communication would 
just happen on the C++-sig list, maybe with the [Boost.Python v3] 
subtitle I've used in this email.

On 08/26/2011 01:09 PM, Dave Abrahams wrote:
>
> Trying to catch up here, so responding to everything all at once.
>
> on Thu Aug 25 2011, Jim Bosch<talljimbo-AT-gmail.com>  wrote:
>
> Just how tall are you, Jimbo?

6'4".  Not that tall, in the grand scheme of things, but it was a 
teenage internet moniker that stuck with me.

>> I'd also like to propose some changes that are slightly
>> backwards-incompatible, as well as some that mess with the internals
>> to an extent that I'd feel better about doing it outside Boost itself,
>> to make it easier for adventurous users to play with the new version
>> without affecting people who depend on having an extremely stable
>> library in Boost.
>
> There's no need to do this "outside of Boost."  A branch in the Boost
> repository is a perfect place for exploratory development that will
> eventually be released as part of Boost.
>> To that end, I'm inclined to copy the library to somewhere else
>> (possibly the boost sandbox, but more likely a separate site), work on
>> it, produce some minor releases, and re-submit it to Boost for
>> review.
>
> If you want to go through another review process, that's up to you.
> Getting review feedback definitely has its advantages.  Please, though,
> use the sandbox or some other area of the Boost svn repository at least
> until we get my hoped-for Git transition completed.

I'd love to see a Git transition too, but I'm actually more familiar 
with SVN at the moment, and I can certainly see the advantages of 
working in the same repository as the previous version.

>
> on Thu Aug 25 2011, Stefan Seefeld<stefan-AT-seefeld.name>  wrote:
>
>>
>> Jim,
>>
>> this is an interesting idea. There has been lots of general (dare I
>> say generic ?) discussion concerning process improvements (which
>> unfortunately most of the time diverted into tool discussions). Among
>> the fundamental issues is a modularization of boost.  I think it would
>> be great if boost.python could follow through on its own, by becoming
>> a separate entity.
>
> Separate from Boost?  I guess that's a possibility but I'm not sure I
> see the advantage.
>

 From my perspective, the advantages are mostly just the same reasons 
Boost has been talking about increased modularity, with regard to having 
stable and development versions for some packages and not for others, 
and to allow users to be able to install some components without 
installing all of them.  Boost.Python (right now, at least) depends on a 
very small core part of Boost, and to my knowledge no other Boost 
libraries have real dependencies on Boost.Python (not counting optional 
dependencies, like the Boost.Graph python bindings).  If/when Boost as a 
whole goes more modular, I think any advantage of being separate would 
disappear, and the ideal case for Boost.Python would be for that to happen.

> on Thu Aug 25 2011, Ralf Grosse-Kunstleve<rwgrosse-kunstleve-AT-lbl.gov>  wrote:
>> Troy and Ravi have done a significant amount of work.
>
> Yes, and hopefully integrating that could be part of any next steps.
>
>> I hope they will comment for themselves.
>>
>> I'd prefer if developments stayed under the boost umbrella, e.g. as
>> boost/python/v3, but I don't feel very strongly about this.
>
> Me too.  We managed a transition from v1 to v2 within Boost, and I think
> we could do the same for v3.
>

Good to hear.  I wasn't using Boost.Python back when that happened, but 
it's nice to know there's a precedent.

Thanks!

Jim