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 bigfatd...@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 _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
