Re: [boost] [modularization] Modularizing Boost (modularization)

Subject: Re: [boost] [modularization] Modularizing Boost (modularization)
From: Stephen Kelly (steveire_at_[hidden])
Date: 2013-10-18 09:12:02

On 10/18/2013 01:18 PM, Beman Dawes wrote:
> On Thu, Oct 17, 2013 at 6:24 PM, Stephen Kelly <steveire_at_[hidden]> wrote:
>
>> Hi there,
>>
>> my plan for modularizing and modernizing Boost was roughly this:
>>
>> * Phase 0 - remove dead weight by bumping compiler feature requirements
>> * Phase 1 - move some files around so that the modularized repos form a
>> mostly directed graph
>> * Phase 2 - Form some kind of 'boost core library' or 'boost feature
>> normalization library' from the guts of existing libraries like
>> type_traits, static_assert, config mpl and utilities.
>> * Phase 3 - Try to port the mpl to variadic templates so that the
>> dependency on Boost.PP is not needed when variadic templates are available.
> Phase 1 was discussed several years ago when modular boost was being
> planned. The decision was to do some limited moving of files around as part
> of the conversion process, but only when necessary. This was part of the
> strategy of limiting modularization changes to simplify the conversion
> process

I have a question. I am not familiar enough with the boost history to
know the answer already:

 Have files ever been moved around in the svn repo before?

If that has never happened, and part of the conversion assumes that all
files were in their present location for their entire history, then that
would help my understanding of what you say about complexity of the
conversion process.

If that has happened before, and the conversion tool is already prepared
to handle moves (as I believe to be the case), then I don't see how
modularizing first adds complexity.

>  and ensure library maintainer buy-in.

Why would a library maintainer object?

Is that a hypothetical, or a real problem?

> Phase 2 was also discussed at length then, and if IIRC the feeling was that
> phase 2 is considerably more complex than it appears on the surface, 

My feeling is not that. Also, the cost of doing it is worth it.

>> Phase 0 is aborted, so let's look at phase 1.
> I wasn't aware that phase 0 was aborted. Why was that?

It is aborted until at least after the 1.55 release is made (I don't
agree with that, as I wrote in the relevant thread, but that is the
current state).

Even after that release is made, you want to do the conversion to git.
After that conversion is done, I am significantly less motivated to do
the phase 0 work because working with git submodules is such an absolute
absence of fun.

Also, I expect that conversion to git will cause weeks or months of
chaos as people who have never ever used it before have to try to work
with it. I don't think attempting to get anything else done in that
period is worthwhile.

Also, I knew as a fact before that 'the boost community doesn't make
decisions. Library maintainers are free to do what they want. Libraries
are not community owned - they are maintainer owned'. I have also
learned that there is an active *expectation* that boost library
maintainers are *not* reading the development mailing list. That is
astounding to me.

Now, after having tried to work in the community on that task I actually
understand those statements more. At least one of the maintainers have
already asked me not to commit to 'their' libraries. Others are putting
unreasonable obstacles in front of me like requiring filing tickets for
each change in each library and CCing each maintainer of all libraries
I'm touching.

I have so far touched 2224 different files:

 stephen_at_hal:~/dev/src/boost-trunk{master}$ git log --stat
--author=skelly | grep -P "^\s*boost" | sed 's#|.*##' | sort | uniq | wc
    2224

I have so far touched 65 different libraries:

stephen_at_hal:~/dev/src/boost-trunk{master}$ git log --stat
--author=skelly | grep -P "^\s*boost" | sed
's#^\s*\(boost/[^/]*\)/.*#\1#' | sed 's#/[^/]*\.hpp.*##' | sort | uniq | wc
     65   

Saying that I have to file tickets and CC maintainers before each change
would have prevented completely what I've done so far, and prevents the
possibilty of continuing the work.

If:

* maintainers were expected to be reading this list (currently they are
expected not to be reading the list),
* and if maintainers are capable of running a grep-like tool to see how
a macro removal will affect the library they maintain (currently that is
not the case
http://thread.gmane.org/gmane.comp.lib.boost.devel/244856/focus=244888),
* and if there was sufficient buy in from maintainers (currently there
is not
http://thread.gmane.org/gmane.comp.lib.boost.devel/244876/focus=244974
http://thread.gmane.org/gmane.comp.lib.boost.devel/244876/focus=244958,
http://thread.gmane.org/gmane.comp.lib.boost.devel/244876/focus=244912).
-- Qt and KDE work by building rough consensus and then making a real
decision, but that does not appear to be how boost works. We 'decided'
to proceed wth my phase 0 work a long time ago, but people keep on
objecting as if it's a new issue.
* or if I had sufficient support from others in the community to argue
actively for movement in this direction

 then it would be possible to continue the work. Despite what it might
look like, I do not enjoy the arguments. Particularly when some of the
replies are such low quality.

As it is, I don't see how the phase 0 work can continue. Please explain
how you think it can.

> The other phases are well worth discussing, particularly once the
> conversion is complete and that giant step is behind us.

You said that phases 1 and 2 were already ruled out years ago. Are you
saying discussing them again is worth it?

I still recommend doing the 'real modularization' before migrating to 68
interdependent git repos. The real modularization can be done in several
steps, and that enables the migration to git to be done in several
steps, as we did in KDE (actually we still have some stuff in svn):

 http://thread.gmane.org/gmane.comp.lib.boost.devel/244984/focus=245026
 
That is my recommendation. You take that as you wish.

Thanks,

Steve.