[boost] [next_generation][modularization] Is the community interested in creating a smooth path to a modularized Boost

Subject: [boost] [next_generation][modularization] Is the community interested in creating a smooth path to a modularized Boost
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2014-05-31 10:18:32

Hi,

I've started a new thread in response to Julian Gonggrijp post 
[modularization] proposal and poll, as I would not answer directly to 
his questions.

I'm sure that almost all of us want a modularized Boost. What does this 
means? It is up to us to define it:
* what the user can request as a delivered package for its own needs?
* what the authors must state explicitly?
* what must be tested/checked?

The main problem is how to achieve it ensuring backward compatibility .

I'm persuaded that we need a new Boost repository (or whatever we want 
to name it) that would include libraries that respect the modularization 
constraints we could define.

My question is who would be interested in starting the next generation 
of a modularized Boost that starts from a repository of ZERO modularized 
libraries. The idea is to add to the current Boost libraries new ones 
that respect the modular rules and adapt the current ones to be defined 
on top of the modularized ones.
At the end we could deprecate the old ones.

In order to do that we need of course to add new interfaces (a new 
namespace mod_boost or whatever is preferred) and so the user would need 
to move to these interfaces smoothly.

Before starting we need to

* Define the constraints of a modularized system
     - no cyclic dependencies,  ....
* Define the tools that can be used to support the modular system
     - which build system(s),
     - which test system(s),
     - which regression system(s),
     - which doc system(s), ...
* Define the rules
     - who could be able allowed to do the refactoring?
     - Should the refactoring be reviewed to ensure a improvement on the 
quality of Boost?
      - who maintains what?, ...
* Setup the infrastructure ( build system, test system, regression 
system, doc system, ... )

Only then we could
* Start from libraries that don't depend on any other library (with 
possible refactoring) and adaptation of the refactored libraries from 
which these modular libraries have been extracted.
* Deliver them
* Build a second layer of libraries that depend only on first layer
* Deliver them

* ...

Of course, in order to check that the rules and tools are the 
appropriated ones we will need to experiment with some examples.

I recognize that this would mean a lot of work, however I hope that the 
final result would satisfy better the community expectations and the 
quality of Boost libraries.

Best,
Vicente