[asterisk-dev] Asterisk to Git Migration Update

[Matthew Jordan]

Hey everyone:

Just as a brief status update on the Asterisk Git Migration project,
here is where we stand today, and what the next steps are:

* The TestSuite has been successfully moved over to Gerrit
(gerrit.asterisk.org), and mirrors have been set up on
git.asterisk.org and GitHub. So far, the usage of Gerrit seems to be
going pretty well, with only a few minor hiccups that have been mostly
handled in #asterisk-dev.

* The repotools project has also been moved over, which will probably
be of more importance later.

* For now, we are handling "Verification" of code review manually,
typically before a patch gets merged into master.

This leads to the next steps:

(1) Set up Zuul and Jenkins. This will allow us to get CI up and
running, and remove the need for a manual Verification of the patches.
For the TestSuite, this may be as simple as running the various unit
tests that are sprinkled throughout /lib/python/asterisk.

(2) Once Zuul/Jenkins are set up, I think we'll be in a position to
actually move the Asterisk repo over to Git. Note that I want to do
this after we release 11.17.0/13.3.0, as that gives us time to make
the necessary changes to the release scripts.

(3) Once the Asterisk repo has been set up, we can create basic build
jobs in Jenkins to provide verification of Asterisk patches.

And ... profit.

There's a large amount of intervening work that has to be done, and
some questions that still need to be answered. In no particular order:

(1) In test runs of building the Asterisk repo, I've successfully
managed to pull in the team repos that are still 'active'. Since
Gerrit acts as the canonical Git repo, we can set it up so that direct
pushes to team branches are allowed and don't require a code review -
although code reviews can be done if someone desires it. For those who
use team branches a lot, does this sound acceptable?

(2) Today, we merge up the branches - 11 => 13, 13 => trunk, etc.
After the move, it looks like the best way to handle the merge process
is going to be to make patches against trunk, then cherry-pick them
back to the currently maintained branches. For long time users of
Gerrit, does this seem appropriate?

(3) In Asterisk 13, we pulled in menuselect (yay). On the downside,
Asterisk 11 doesn't have menuselect. What's more, Asterisk 1.8 and 12
are still in security fix mode. We really have two options here:
  (a) Update the build scripts to pull in menuselect as they do now
from SVN, and more or less keep the existing process. My fear is that
this may turn into a bit of hackery to keep the Git/SVN lines from
getting confused.
  (b) Bite the bullet and just backport menuselect into all the
branches. Moving to Git is going to be a "breaking" change for people
using Asterisk 11 anyway, and this way things end up in a reasonably
pristine state.
   Thoughts?

(4) Asterisk records the SVN revision in each file using the special
keyword "$Revision:". This is then registered in a linked list for
retrieval by the CLI/AMI. Unfortunately, Git doesn't support this
concept, as adding data into a file after commit would change the
checksum . It does allow doing this on checkout via the $Id$ keyword,
which may be an acceptable workaround.

Anyway, the goal is to kick off the move of Asterisk to Git
immediately after we get the next batch of releases out. I'll send out
an e-mail once we know exactly when that is.

Thanks!

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org