Subject: Re: [boost] Git Modularization Ready for Review
From: Dave Abrahams (dave_at_[hidden])
Date: 2013-05-07 00:11:02
on Mon May 06 2013, "Vicente J. Botet Escriba" <vicente.botet-AT-wanadoo.fr> wrote:
> Le 06/05/13 07:34, Dave Abrahams a Ã©crit :
>> on Sun May 05 2013, "Vicente J. Botet Escriba" <vicente.botet-AT-wanadoo.fr> wrote:
>>> Le 04/05/13 21:08, Dave Abrahams a Ã©crit :
>>>> Hi All,
>>>> After substantial work, including massive changes by me and Daniel
>>>> Pfeifer to KDE's svn->Git conversion tool, we have captured every Boost
>>>> SVN commit in a Git repository. You can view the results at
>>>> or you can pull from these repositories and view them in your local
>>>> The conversion process is automated by
>>>> http://jenkins.boost.org/job/Boost2Git/ using the tool at
>>>> The rules that describe how commits are distributed are
>>>> in https://github.com/ryppl/Boost2Git/blob/master/repositories.txt
>>>> To understand how to edit that file, please read
>>>> Daniel and I are ready to accept your feedback on the results of
>>>> modularization, and especially your pull requests containing edits to
>>>> the ruleset. I will the steering committee to establish a formal review
>>>> period, though.
>>> Now that the it is ready for review, could you point where is the
>>> documentation to review?
>> Sorry, what documentation?
> What is ready for review then, the split on modules?
The way the modules are being split up, and the resulting Git histories.
>>> Could I move the following from repository thread to core?
>>> "boost/detail/atomic_redef_macros.hpp" :
>>> "boost/detail/atomic_undef_macros.hpp" :
>>> "include/boost/detail/atomic_undef_macros.hpp"; I added these
>>> files. They are used now by Boost.Thread, but it should be used by
>>> SmartPtr (See https://svn.boost.org/trac/boost/ticket/6842 and
>>> https://svn.boost.org/trac/boost/ticket/6843). Best, Vicente
>> First, are you sure they don't belong in their own module?
>> It might be a good idea to minimize the size of the core "blob."
> Where this kind of workarounds should go, Boost.Config?
Oh, I didn't realize they were just workarounds. Perhaps core would be
>> Second, sure, we can do that. Please try editing the ruleset yourself
>> and submitting a pull request as described above. We need to find out
>> if our instructions are adequate.
> I'm not sure I know how this must be done :(
There's only one way to find out!
> Anyway, I will try.
-- Dave Abrahams
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk