El anuncio oficial

Hey everyone –

As an update on the Git migration, here is the current state of the world:

1. The SVN repos have been marked read-only. While you will still beable to checkout from SVN, you shouldn’t commit to any of thebranches. Note that even if you do, those commits won’t make it intothe Git repos – so it’s not really a good idea to try 🙂

2. The project has been moved over to a Git repo under Gerrit(https://gerrit.asterisk.org). You can clone the project using theinstructions on the ‘asterisk’ repo project page:https://gerrit.asterisk.org/#/admin/projects/asterisk Thanks goes toGeorge Joseph for quickly getting a .gitignore/.gitreview file up forreview and included in the repo.

3. Mirrors for the project have been set up on git.asterisk.org andGithub. These mirrors are particularly useful for providing sourcebrowsing of the repo.

4. A patch has been put up against ‘master’ to rework the source fileversion macros. By rework, I mostly mean “remove”, although the macroitself could not be fully removed due to other features relying on thefile name being registered. See https://gerrit.asterisk.org/#/c/54/for more details.

So what are some immediate next steps?

1. We need to determine the best way to handle maintaining the longrunning branches. While rebasing is appropriate for topic branches(team branches) that closely track a mainline branch, the mainlinebranches are a bit different. They not only don’t have ever commitmerged into them (either going ‘up’ from 11 => 13 => master or ‘down’from master => 13 => 11), but patches are highly likely to mergecleanly. ABI issues in 11/13 are a bigger concern than those inmaster; APIs will have changed; etc.

As a result, my initial plan was to have developers cherry-pick to themainline branches as appropriate, with the initial commit being doneto ‘master’. There are some downsides to this approach: a) Each cherry-pick has to be reviewed. This can make it difficultto track the reviews, as each review is completely separate from theothers. b) Cherry-picks through the Gerrit UI will not always work. Folkswill need to be careful when cherry-picking back to a branch thatrequires fixing merge conflicts, as getting the Change ID correct insuch a case is important to keep all of the Gerrit reviews tiedtogether. c) We’ll be changing our process from merging ‘up’ branches to‘down’ branches. Change is scary.

I think we’re going to need some time to work through the implicationsof how we handle the mainline branches. I suggest hanging out in#asterisk-dev over the next few days as we work through the details.In the meantime, I’ve restored the TEST-Asterisk repo so folks canplay around with the cherry-picking, and/or other models of branchmaintenance. I certainly welcome any suggestions on the best way tomake the process work.

2. Russell noted in George’s .gitreview/.gitignore review(https://gerrit.asterisk.org/#/c/42/) that we may want to include thefullname of contributors/users along with their e-mail address. Ithink that’s a good idea, but that would mean updating our commitmessage template, script, and our process. Comments/suggestionswelcome here on that proposal.

3. The ‘make update’ Makefile target needs to be updated. If you havesome Makefile-foo and git-foo and would like to look at that, that’dbe awesome.

Over the next few days, I’ll be updating the Asterisk wiki pages withmore information. I’ll reply to this thread as that happens. If youhave any questions, please don’t hesitate to reply here or jump in#asterisk-dev.