On Sat, Apr 11, 2015 at 10:15 PM, Matthew Jordan <mjor...@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 >
-- _____________________________________________________________________ -- 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