[boost] Status of GIT and BOOST

Subject: [boost] Status of GIT and BOOST
From: Marshall Clow (mclow.lists_at_[hidden])
Date: 2012-05-29 16:41:44

[ reposted in its own thread so that it is less easily missed ]

Synopsis:
=========
The Boost Steering Committee has agreed IN PRINCIPLE to move ahead with
the migration to Git and to a modular repository structure.

What?
=====
Development of Boost will move from a monolithic subversion repository
to the much-discussed Git repository structure consisting of one
super-module that points (via submodules) to other repositories, each
containing an individual Boost library. The Git repositories will be
hosted on github.

Although Boost will move to a distributed development model, it will
still be tested and released as a unified whole. There will be scripts
to reassemble the monolithic Boost from its constituents.

The development work flow need not change for contributors. They have
the option to check out boost super-module and all the submodules,
execute the script to make a monolithic whole, and develop and test as
usual.

It is currently an open question what to do about issue tracking once we
move to modularized repos. Both Github and Redmine have been suggested
as possible solutions that would give users a unified way to search for
bugs across all of boost. The migration will NOT take place before this
issue is settled.

Why?
====
Boost is big and getting bigger. We've been experiencing scalability
problems with our tools and with our release and testing procedures for
a while now. The problem is bigger than "subversion commands are slow".
Moving a large, diverse library collection forward in lock-step slows
down progress. Our solutions to the scalability problems have themselves
caused problems. We don't branch from trunk for our releases. Changes
languish on trunk because people forget to merge them. Trunk is a wild
west where test results for any one library are often broken due to
requirements shifting from under it, causing confusion about whether a
change can be safely merged to release. And the converse is also true:
just because tests are green on trunk is no assurance that a change
won't cause problems on release.

The solution is to free each library to evolve independently within its
own repository. Boost is a collection of the last stable releases of
each of its constituent libraries. Library maintainers develop and test
against this latest stable library collection and issue rolling releases
on their own timetable. Release managers pick which versions of each
library to include and have the option to temporarily fork a library to
correct integration issues to get a release out, issuing pull requests
to get the fixes upstream. The result is a more dynamic, loosly-coupled
ecosystem where both the individual libraries and Boost as a whole can
move forward more quickly.

How?
====
The modular git repositories have already been created along with a
script to populate them automatically. At some point, the old svn repo
will be locked permanently and the modular git repos will be
re-populated from svn. John Wiegley has worked on a script to do the
conversion with perfect fidelity. A separate git repo with all of
Boost's history will be created such that it can be grafted on to each
submodule if desired. That way, each submodule can share history with
all the others (a significant space win). The test and release scripts
and the website will be updated to account for the new development
model. From that point forward, all development will take place in the
git repos.

The old Trac will eventually be locked and archived. Whatever issue
tracking solution we come up with, tickets must be migrated. The plan is
still coming together here. Bear with us.

When?
=====
The approval is IN PRINCIPLE and not IN FACT at this point because the
necessary pieces are not yet all in place. In particular, issues such as
trac integration and testing are not yet settled. Also, we want a script
in hand that verifies that no changesets are lost or munged in the
svn->git migration.

Once the steering committee is satisfied that all the pieces are in
place, we'll give a final go-ahead, the dates will be announced, and the
transition will take place. An ETA is hard to predict at this point, but
we are aiming for making the switch in the next few months. Possibly
after 1.50 or 1.51.

Comments:
=========
The Boost Steering Committee understands that there is general but not
universal support in the Boost community for this migration. The
committee came this to decision after long analysis of the ongoing
problems facing Boost, and of the merits of the proposed migration. It
is the role of the Steering Committee to make difficult decisions like
this, even when the wider community is unable to reach universal
consensus. We will do everything to make this transition as painless as
possible, and to give those not comfortable with git the support they
need. We all appreciate your understanding.

THANKS:
=======
Thanks are due to the many people who have worked over the past few
years to make this transition happen, including:

Dave Abrahams
Daniel Pfeifer
John Wiegley
Beman Dawes
Eric Niebler
Troy Straszheim

Thanks, guys! Here's to making Boost better, faster and stronger.

--Your friendly neighborhood steering committee
Beman Dawes
Dave Abrahams
Hartmut Kaiser
Jeff Garland
Jon Kalb
Marshall Clow
Robert Stewart
Steven Wantanabe

-- Marshall

Marshall Clow     Idio Software   <mailto:mclow.lists_at_[hidden]>

A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait).
        -- Yu Suzuki