Re: [boost] [git] Some questions on Git transition

Subject: Re: [boost] [git] Some questions on Git transition
From: Dave Abrahams (dave_at_[hidden])
Date: 2013-08-24 16:01:36

on Wed Aug 21 2013, Daryle Walker <darylew-AT-hotmail.com> wrote:

> * I see we have a GitHub account at https://github.com/boostorg, with
> repositories for each library.  

Yes, those repositories are being generated dynamically from SVN by
https://github.com/ryppl/Boost2Git#boost2git

> If we add a new library, and it has been Git-based, are we going to
> mirror it in the Boost account?

Well, we'll have a repo for it under github.com/boostorg/, which will be
where the official Boost releases are made from.

> That'll make sure if something happens to the original, we still have
> a last-known-good to work with.  Would having all the libraries (or
> copies/mirrors) under the same account make scripts easier?  

Yes, and we plan to do that.

> What about non-Git libraries, will they be copied over?  

What's a non-Git library?  Serious question.

> Would a bridge be used?  (There's at least bridges for Git connecting
> to either Subversion or Mercurial.)

Boost libraries will be officially developed under Git.  People can use
bridges or other tools to develop if they like, but Git is going to be a
requirement for Boost libraries going forward.

> * We currently ship all the libraries merged together as a single
> archive.  Some package managers even provide the Boost libraries as a
> single item.  When we go Git, is that still going to be in place (with
> the release managers doing some sort of merging script), or are we and
> every user going to move to doing several dozen downloads instead?
> (And everyone has to figure out how to use more than one Boost library
> at once.)

There are two answers to this, no and no. :-)

The first "no" is that we are also producing
https://github.com/boostorg/boost, which is a monolithic snapshot of
everything that refers to the other repositories as submodules.  All of
Boost's SVN history is captured there, and after the transition each
whole-Boost release and release candidate will be available in that
repository as a tag.

The second "no" is that Ryppl is intended to be a tool that manages
inter-library dependencies and resolves them for you as needed, so that
you don't have to grab all of Boost just to do a bit of development.
But Ryppl is a long-term goal, not a short-term reality.

> * Are we eventually going to use something like
> http://nvie.com/posts/a-successful-git-branching-model/?  

We have already agreed to use exactly that model (git-flow).

> If so, are we going to use that to script releases?  (At release-time,
> grab the latest version of each library from their master branches,
> apply the merging script, run tests, then ship.)

What merging script? :-)

The plan for monolithic Boost releases is to continuously test a
revision of http://github.com/boostorg/boost whose submodule references
point only to release tags in each sub-repository.  When the release
managers like those test results, they can ship the release.

-- 
Dave Abrahams