Re: [Boost-users] What's happened to Ryppl?

28 Jan 2011

      Dave Abrahams wrote:
...
On Thu, Jan 27, 2011 at 1:26 PM, Robert Ramey  wrote:
...
Beman Dawes wrote:
...
...
Independent of modularization, ryppl, or anything else, is it time
to start a discussion on the main list about moving to Git?
To me, this illustrates a fundamental problem. If the issue of
modularization were addressed, there would be no requirement
that all libraries use the same version control system. That is,
change to a different version control system would occur
one library at time.
Same can be said for the build system.
In principle, true.  In practice, we need some consistency across
boost or it will become hard for the community to contribute, and
especially hard for people (including release managers) to step in and
fix things, or even assemble a distribution.  This is to say nothing
of automated testing.
...
The only coupling really required between libraries is
a) namespace coordination
b) directory structure - to some extent at least at the top levels
c) quality standards
d) testing
introduces a build system dependency.
A particular library will depend upon at least one build/test
system.  But that doesn't imply that all libraries have to depend
on the same one.  In fact, we already have the situation that
many (all?) libraries can be built/tested with bjam or Ctest.

The "boost test" would be just the union of the test procedure
implemented for each library.  That is

foreach(library L)
    lib/L/test/test.bat // or /lib/L/test.sh

The current approach implements the view of Boost as a
particular set of libraries ONLY built/tested/distributed as an
whole.

My view is that is not scaling well and can never do so.

Each library should be "buildable, testable, and distributable"
on it's own.  The "official boost distribution" would be just
the union of all the certified boost libraries.  Of course anyone
could make his own subdistribution if he want's to.  Already
we have a step in this direction with B?P (distribute one library
and all it's pre-requisites).

I envision the future of boost that looks more like sourceforge
but with all libraries meeting the boost requirements.  I see boost
as spending more time on reviews and less time on testing,
packaging, etc. I see "packaging/distribution" as being handled
by anyone who wants to create any subset of the boost libraries.
Finally, I see the testing as being done by each user to get
a wider coverage.

I see the centralized functions being limited to:
a) reviews/certification
b) accumulation of testing results
c) coordination/maintainence of standards (a-d above)
d) promotion of developer practices compatible with
the above (licenses, etc).

Suppose such an environment existed today.  The whole
issue of moving to git wouldn't be an issue.  Each library
author could use which ever system he preferred.  Movement
to git could proceed on a library by library basis if/when
other developers were convinced it was an improvement.
It would be one less thing to spend time on.
...
...
ii) platform coverage
iii) documentation requirements
If coupling is required somewhere else, it's an error that
is holding us back.
I don't believe such an error exists here.
Robert Ramey