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

On Tue, May 29, 2012 at 10:12 AM, Lars Viklund <zao@acc.umu.se> wrote:

On Tue, May 29, 2012 at 05:31:20AM -0700, Marshall Clow wrote:

...

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.

I hope that this is coupled with very clear and unambigious instructions on things like "how to work in submodules", as that's something which I have repeatedly misunderstood and successfully use to completely destroy my own repositories.

We need proper documentation and operating procedures, preferably something that has been well tested in our future configuration.

Yes, for sure. Each of the common development scenarios needs to be covered: * Setup a clone for development work. * Doc fix. * Simple bug fix. * Complex bug fix best done on branch. * Minor feature branch for next release. * Major feature branch for future release. * Tag and release a new version of the library. We also need a virtual "Git Help Desk" so developers can get quick and accurate answers to questions. Maybe that's as simple as tagging subject lines [git help]. Help will be particularly important when a developer runs into trouble. --Beman

I appreciate the effort that went into this consideration. I have a related question.. Does anyone know of a seamless way to use mercurial as a "front-end" to Git? Or rather more generally.. How would one go about living with Boost living in Git and wanting to instead use Merculrial (or anything else for that matter) for ones project instead?

Apparently there's already a way to use git repos with mercurial, see http://hg-git.github.com Also, bitbucket supports both git & mercurial ( http://blog.bitbucket.org/2011/10/03/bitbucket-now-rocks-git), so at worse it'd be a matter of some ping pongs between the real git repo and bitbucket. Philippe

On May 28, 2012, at 9:31 PM, Julien Nitard wrote:

Hi all,

On a slightly unrelated topic, will there be videos of said revelations posted online like last year ?

I am working on the videos as I type this message ;-) -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki