Re: [asterisk-dev] Asterisk to Git Migration Update
On Tue, Mar 31, 2015 at 7:54 PM, Matthew Jordan wrote: > On Tue, Mar 31, 2015 at 1:48 PM, Russell Bryant > wrote: > Yeah, I think I'd rather just bite the bullet and get the repo set up > "right" with as few weird things lingering around as possible. The > only potential issue is requiring libxml2 (as we didn't pull in the > bundled mxml) - but we may as well deal with the fallout now. Maybe for 11 we can just import menuselect and mxml SVN repos into the GIT branch 11 with no modifications. This way there would be no changes in dependencies. >>> (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. >> >> >> That whole thing seems questionably useful, anyway. Just removing it is >> another option. > > True. I'm not sure how much value people get from knowing the SVN > revision of a file... much less a checksum. Checksums would only be useful if they were generated at build-time from the complete source file, and a file or URL with a list of official checksums was available. This would allow a CLI command to list unofficial/modified sources, could make it easier to identify when bugs are caused by those changes. -- _ -- 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
Re: [asterisk-dev] Asterisk to Git Migration Update
On Tue, Mar 31, 2015 at 1:48 PM, Russell Bryant wrote: > On Tue, Mar 31, 2015 at 2:32 PM, Matthew Jordan wrote: >> >> >> 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? > > > What's the benefit of trying to keep team branches at all vs. just letting > people use their own git trees hosted on one of the many personal git > hosting options (github or whatever) ? > > If it's about several people collaborating on a branch, that makes sense to > me to do as a feature branch in gerrit, but it seems like the exception, not > the rule. > I think the primary benefit is having a place for collaborators to put stuff. If anything - since we won't have to worry about SSL access to SVN - the move to Gerrit will make that *must* easier for people. The secondary benefit is having a location for people who have signed a CLA to push code, and implicit in that push, that they've licensed that code back to the Asterisk project. > > (b) sounds the least painful overall to me. People consuming releases > shouldn't notice a difference, right? Yeah, I think I'd rather just bite the bullet and get the repo set up "right" with as few weird things lingering around as possible. The only potential issue is requiring libxml2 (as we didn't pull in the bundled mxml) - but we may as well deal with the fallout now. >> (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. > > > That whole thing seems questionably useful, anyway. Just removing it is > another option. True. I'm not sure how much value people get from knowing the SVN revision of a file... much less a checksum. -- 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
Re: [asterisk-dev] Asterisk to Git Migration Update
On Tue, Mar 31, 2015 at 2:32 PM, Matthew Jordan wrote: > Hey everyone: > Hi! > Just as a brief status update on the Asterisk Git Migration project, > here is where we stand today, and what the next steps are: > Awesome work so far. :-) > 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? > What's the benefit of trying to keep team branches at all vs. just letting people use their own git trees hosted on one of the many personal git hosting options (github or whatever) ? If it's about several people collaborating on a branch, that makes sense to me to do as a feature branch in gerrit, but it seems like the exception, not the rule. > (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? > Yes. > (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? > (b) sounds the least painful overall to me. People consuming releases shouldn't notice a difference, right? (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. > That whole thing seems questionably useful, anyway. Just removing it is another option. 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. \o/ -- Russell Bryant -- _ -- 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
[asterisk-dev] Asterisk to Git Migration Update
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 -- _ -- 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
