[C++-sig] [Boost.Python v3] Planning and Logistics
dave at boostpro.com
Sat Aug 27 22:29:56 CEST 2011
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.
> 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
>> 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:
>>> 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.
More information about the Cplusplus-sig