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

[Dave Abrahams]

on Fri Aug 26 2011, Jim Bosch <talljimbo-AT-gmail.com> wrote:

> 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.  

It's all the same repository.  Working in the sandbox is essentially
equivalent to working in a branch of trunk; it's just a matter of where
the code lives in the SVN directory hierarchy.

> 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.

Sure.

> 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.

Oh, then I should change my email to bigfatdave at somewhere.com

>>> 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.

In that case, if I were you, I would actually start using Git with the
modularized / CMake-ified Boost at http://github.com/boost-lib.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com