[asterisk-dev] Git Migration update

[George Joseph]

On Sat, Apr 11, 2015 at 10:15 PM, Matthew Jordan <mjordan at digium.com> wrote:

> 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 be
> able to checkout from SVN, you shouldn't commit to any of the
> branches. Note that even if you do, those commits won't make it into
> the 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 the
> instructions on the 'asterisk' repo project page:
> https://gerrit.asterisk.org/#/admin/projects/asterisk  Thanks goes to
> George Joseph for quickly getting a .gitignore/.gitreview file up for
> review and included in the repo.
>
> 3. Mirrors for the project have been set up on git.asterisk.org and
> Github. These mirrors are particularly useful for providing source
> browsing of the repo.
>
> 4. A patch has been put up against 'master' to rework the source file
> version macros. By rework, I mostly mean "remove", although the macro
> itself could not be fully removed due to other features relying on the
> file 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 long
> running branches. While rebasing is appropriate for topic branches
> (team branches) that closely track a mainline branch, the mainline
> branches are a bit different. They not only don't have ever commit
> merged into them (either going 'up' from 11 => 13 => master or 'down'
> from master => 13 => 11), but patches are highly likely to merge
> cleanly. ABI issues in 11/13 are a bigger concern than those in
> master; APIs will have changed; etc.
>
> As a result, my initial plan was to have developers cherry-pick to the
> mainline branches as appropriate, with the initial commit being done
> to 'master'. There are some downsides to this approach:
>   a) Each cherry-pick has to be reviewed. This can make it difficult
> to track the reviews, as each review is completely separate from the
> others.
>   b) Cherry-picks through the Gerrit UI will not always work. Folks
> will need to be careful when cherry-picking back to a branch that
> requires fixing merge conflicts, as getting the Change ID correct in
> such a case is important to keep all of the Gerrit reviews tied
> together.
>   c) We'll be changing our process from merging 'up' branches to
> 'down' branches. Change is scary.
>
>
I'm wondering if we can do this...

You submit a review on the lowest target branch, using 13 as an example.
The review gets reviewed and merged into 13.  Once the review is closed
gerrit won't allow a cherry-pick but git of course has no problems with
it.  So maybe we can write/obtain a hook/plugin that allows the submitter
to cherry-pick the change directly into the target branch, say master,
bypassing the review process, assuming a clean merge.

Alternative...  We normally don't have access to commit to refs/head
directly but what if we had a hook that allowed a commit to be merged
directly IF the commit-id/change-id matched a review already approved and
merged to the original branch.

Off to bed. :)



> I think we're going to need some time to work through the implications
> of 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 can
> play around with the cherry-picking, and/or other models of branch
> maintenance. I certainly welcome any suggestions on the best way to
> make the process work.
>
> 2. Russell noted in George's .gitreview/.gitignore review
> (https://gerrit.asterisk.org/#/c/42/) that we may want to include the
> fullname of contributors/users along with their e-mail address. I
> think that's a good idea, but that would mean updating our commit
> message template, script, and our process. Comments/suggestions
> welcome here on that proposal.
>
> 3. The 'make update' Makefile target needs to be updated. If you have
> some Makefile-foo and git-foo and would like to look at that, that'd
> be awesome.
>
> Over the next few days, I'll be updating the Asterisk wiki pages with
> more information. I'll reply to this thread as that happens. If you
> have any questions, please don't hesitate to reply here or jump in
> #asterisk-dev.
>
> Thanks!
>
> Matt
>
> --
> 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
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150412/cb039801/attachment.html>