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

On 10/18/2013 01:18 PM, Beman Dawes wrote:

On Thu, Oct 17, 2013 at 6:24 PM, Stephen Kelly 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@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@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.