On May 23, 2012, at 1:10 PM, Beman Dawes wrote:
Be a day or two more before we get a chance to post details. Stay tuned!
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