Re: [asterisk-dev] Git Migration update
On Tue, Apr 14, 2015 at 9:24 AM, Russell Bryant russ...@russellbryant.net wrote: On Mon, Apr 13, 2015 at 6:52 PM, Matthew Jordan mjor...@digium.com wrote: For *right now*, we are going to try cherry-picking the changes to the affected branches when the change is first up for review. This is clearly a pretty big change in process, as the act of merging into other branches was (a) always done by those with commit access and (b) never reviewed. There's at least two good reasons to give this a try: (1) There isn't anyone with commit access. Anyone can post a review up to Gerrit. The plus side is that there are far fewer barriers to getting a patch into Asterisk. The downside is that there isn't a select group of people who have been trusted to do the merges. The only way to ensure that patches actually do get merged into all the branches is to require people to put the patches up with the initial review. (2) Gerrit really, really wants to review things. That's a good thing: we've had plenty of bad merges take out branches in the past - either from compilation issues, subtle bugs that creep in due to API compatibility problems, etc. We've had even more that get merged upstream and fail to take advantage of APIs that exist in later versions of Asterisk. Reviews will help to catch that. This is a trial. We'll re-evaluate how things are working at the end of the week. So, tentatively, I think the model of cherry-picking changes to all affected branches (including master) is working out okay. This does mean the volume of code reviews has gone up, but we appear to be keeping reasonable pace with the changes. One of the benefits of Gerrit is that while the volume of code reviews is greater, it is: (1) FAR easier to get changes merged in, particularly when the entire change is now reviewed for all branches. (2) Much more collaborative, as anyone can address findings and/or fix up commits and update reviews. As such, I've gone ahead and updated the various wiki pages (with some help from Corey and George) to note the Git related policies. The major pages are: * Patch Contribution Process (https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process) A very high level page that details for new(er) developers how to submit a patch to the project. It's also a good overview for everyone, and links to many of the pages below. * Git Usage (https://wiki.asterisk.org/wiki/display/AST/Git+Usage) This brief page lists out the various Git repositories (mirrors and the like), and specific recommendations for how the -2+2 reviews should be handled. * Gerrit Usage (https://wiki.asterisk.org/wiki/display/AST/Gerrit+Usage) This rather detailed page contains instructions for using Gerrit and git review. * Commit Messages (https://wiki.asterisk.org/wiki/display/AST/Commit+Messages) Details proper formatting of commit messages. Since the commit messages are also reviewed, this is important for everyone. * Software Configuration Management Policies (https://wiki.asterisk.org/wiki/display/AST/Software+Configuration+Management+Policies) Details the types of branches in Asterisk (Standard vs LTS), new feature/bug fix policies, as well as the currently supported branches. Most of this should be familiar to long-time developers of Asterisk, and not much has changed here. I'm sure there is information that is still missing or unclear. If you have any questions about the content on the pages above, please feel free to ask here on the mailing list or in #asterisk-dev, and I (or others) will work to get them cleared up. 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
Re: [asterisk-dev] Git Migration update
On Mon, Apr 13, 2015 at 6:52 PM, Matthew Jordan mjor...@digium.com wrote: For *right now*, we are going to try cherry-picking the changes to the affected branches when the change is first up for review. This is clearly a pretty big change in process, as the act of merging into other branches was (a) always done by those with commit access and (b) never reviewed. There's at least two good reasons to give this a try: (1) There isn't anyone with commit access. Anyone can post a review up to Gerrit. The plus side is that there are far fewer barriers to getting a patch into Asterisk. The downside is that there isn't a select group of people who have been trusted to do the merges. The only way to ensure that patches actually do get merged into all the branches is to require people to put the patches up with the initial review. (2) Gerrit really, really wants to review things. That's a good thing: we've had plenty of bad merges take out branches in the past - either from compilation issues, subtle bugs that creep in due to API compatibility problems, etc. We've had even more that get merged upstream and fail to take advantage of APIs that exist in later versions of Asterisk. Reviews will help to catch that. This is a trial. We'll re-evaluate how things are working at the end of the week. Instructions for cherry-picking changes are on a draft wiki page here: https://wiki.asterisk.org/wiki/display/AST/Git+Usage One thing that helps tracking backports is using the same Change-Id for the same patch applied to multiple branches. You can use that Id to check the status of a single patch across all branches. For example, I saw this patch that's proposed for both master and 13: https://gerrit.asterisk.org/#/q/Id0ce0528e58014da1324856ea537e7765466044a -- 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
Re: [asterisk-dev] Git Migration update
On Mon, Apr 13, 2015 at 5:15 PM, George Joseph george.jos...@fairview5.com wrote: On Mon, Apr 13, 2015 at 5:02 PM, Matthew Jordan mjor...@digium.com wrote: On Mon, Apr 13, 2015 at 5:52 PM, Matthew Jordan mjor...@digium.com wrote: On Sun, Apr 12, 2015 at 1:57 AM, George Joseph george.jos...@fairview5.com wrote: On Sat, Apr 11, 2015 at 10:15 PM, Matthew Jordan mjor...@digium.com wrote: snip Further updates after Day 2 (3?): 1. Due to popular request, the code review e-mails (which were nearing spam levels) are going to be redirected to a new mailing list. The new mailing lists is asterisk-code-review - see http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-code-review 2. All branches should have .gitignore/.gitreview files, including 1.8/12 3. Versions should be reported correctly in Git branches. A review is up now to get the Test Suite understanding things. Items on the short-list to figure out: 1. Backport menuselect into 1.8, 11, and 12 I can take this one. 2. Fix (or investigate) build failures that occur when switching between branches. I'm not sure if anyone else has run into this yet, but ./configure make tends to get stuck on menuselect rather hard, and I'll have to run a 'make clean' to get things moving again, which is weird. I'll take this as well since I'm going to be mucking with menuselect anyway. 3. Fix 'make update' 4. Document how to push to team branches, and make sure that works as expected 5. Update the Gerrit web links module to point to our instructions on Git/Gerrit 6. Tackle the repotools release-summary scripts There's plenty more after that, but that's on my short-term punch list. If anyone would like to look at any of those items (apart from the muck with Gerrit modules item, at any rate), feel free to help yourself :-) -- _ -- 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] Git Migration update
On Mon, Apr 13, 2015 at 5:52 PM, Matthew Jordan mjor...@digium.com wrote: On Sun, Apr 12, 2015 at 1:57 AM, George Joseph george.jos...@fairview5.com wrote: On Sat, Apr 11, 2015 at 10:15 PM, Matthew Jordan mjor...@digium.com wrote: snip Further updates after Day 2 (3?): 1. Due to popular request, the code review e-mails (which were nearing spam levels) are going to be redirected to a new mailing list. The new mailing lists is asterisk-code-review - see http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-code-review 2. All branches should have .gitignore/.gitreview files, including 1.8/12 3. Versions should be reported correctly in Git branches. A review is up now to get the Test Suite understanding things. Items on the short-list to figure out: 1. Backport menuselect into 1.8, 11, and 12 2. Fix (or investigate) build failures that occur when switching between branches. I'm not sure if anyone else has run into this yet, but ./configure make tends to get stuck on menuselect rather hard, and I'll have to run a 'make clean' to get things moving again, which is weird. 3. Fix 'make update' 4. Document how to push to team branches, and make sure that works as expected 5. Update the Gerrit web links module to point to our instructions on Git/Gerrit 6. Tackle the repotools release-summary scripts There's plenty more after that, but that's on my short-term punch list. If anyone would like to look at any of those items (apart from the muck with Gerrit modules item, at any rate), feel free to help yourself :-) -- 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] Git Migration update
On Mon, Apr 13, 2015 at 5:02 PM, Matthew Jordan mjor...@digium.com wrote: On Mon, Apr 13, 2015 at 5:52 PM, Matthew Jordan mjor...@digium.com wrote: On Sun, Apr 12, 2015 at 1:57 AM, George Joseph george.jos...@fairview5.com wrote: On Sat, Apr 11, 2015 at 10:15 PM, Matthew Jordan mjor...@digium.com wrote: snip Further updates after Day 2 (3?): 1. Due to popular request, the code review e-mails (which were nearing spam levels) are going to be redirected to a new mailing list. The new mailing lists is asterisk-code-review - see http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-code-review 2. All branches should have .gitignore/.gitreview files, including 1.8/12 3. Versions should be reported correctly in Git branches. A review is up now to get the Test Suite understanding things. Items on the short-list to figure out: 1. Backport menuselect into 1.8, 11, and 12 I can take this one. 2. Fix (or investigate) build failures that occur when switching between branches. I'm not sure if anyone else has run into this yet, but ./configure make tends to get stuck on menuselect rather hard, and I'll have to run a 'make clean' to get things moving again, which is weird. 3. Fix 'make update' 4. Document how to push to team branches, and make sure that works as expected 5. Update the Gerrit web links module to point to our instructions on Git/Gerrit 6. Tackle the repotools release-summary scripts There's plenty more after that, but that's on my short-term punch list. If anyone would like to look at any of those items (apart from the muck with Gerrit modules item, at any rate), feel free to help yourself :-) -- _ -- 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] Git Migration update
On Sun, Apr 12, 2015 at 1:57 AM, George Joseph george.jos...@fairview5.com wrote: On Sat, Apr 11, 2015 at 10:15 PM, Matthew Jordan mjor...@digium.com wrote: 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. As an update to everyone: For *right now*, we are going to try cherry-picking the changes to the affected branches when the change is first up for review. This is clearly a pretty big change in process, as the act of merging into other branches was (a) always done by those with commit access and (b) never reviewed. There's at least two good reasons to give this a try: (1) There isn't anyone with commit access. Anyone can post a review up to Gerrit. The plus side is that there are far fewer barriers to getting a patch into Asterisk. The downside is that there isn't a select group of people who have been trusted to do the merges. The only way to ensure that patches actually do get merged into all the branches is to require people to put the patches up with the initial review. (2) Gerrit really, really wants to review things. That's a good thing: we've had plenty of bad merges take out branches in the past - either from compilation issues, subtle bugs that creep in due to API compatibility problems, etc. We've had even more that get merged upstream and fail to take advantage of APIs that exist in later versions of Asterisk. Reviews will help to catch that. This is a trial. We'll re-evaluate how things are working at the end of the week. Instructions for cherry-picking changes are on a draft wiki page here: https://wiki.asterisk.org/wiki/display/AST/Git+Usage -- 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] Git Migration update
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
Re: [asterisk-dev] Git Migration update
On Sat, Apr 11, 2015 at 11:15 PM, Matthew Jordan mjor...@digium.com wrote: 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. Ugh. This is what I get for writing this at 23:15. The gist of this paragraph is: I don't think 'git merge' will work well on mainline branches, regardless of the order in which we merge. I suspect we're going to want to cherry-pick. -- 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] git migration update
On Mon, Dec 29, 2014 at 9:47 AM, Matthew Jordan mjor...@digium.com wrote:
On Mon, Dec 22, 2014 at 9:01 PM, Tzafrir Cohen tzafrir.co...@xorcom.com
wrote:
Hi,
Thanks for the update.
On Mon, Dec 22, 2014 at 01:03:17PM -0600, Samuel Galarneau wrote:
Just wanted to update everyone on the git migration status and illicit some
feedback on a few items.
We setup an instance of Gerrit and Jenkins internally, imported the
Asterisk testsuite into a git repo, and configured Gerrit and Jenkins
together.
Just a note: currently we have two pending reviews of patches by
private mails in dahdi: one in dahdi-linux and one in dahdi-tools. I
wonder when we can start using Gerrit.
2 - we have a few options as far as team branches go. We could configure
user branches using refs/heads/team/${username}/* permissions in Gerrit to
allow users to create branches. This would prohibit other users from
pushing to a user branch, but they would still be visible. This would most
likely involve reproducing some sort of automerge/autorebase process. The
other option is to use github as another remote for team branches, with a
remote pointing to Gerrit for code reviews. Is there a preference between
these two approaches, or perhaps a better setup we could follow?
What if I have my own git server (which is not github)?
But then again, why are team branches needed? When I work on my own
branch I keep it in sync with the main development branch manually. If I
don't work on it, it will fall back, but merging the changes (or
rebasing) should be easy with git. And if I want to work on someone
else's branch I can do this sync on my own.
I don't think I'd want automerge. Autorebase is probably bad as you
can't clone that branch. If I rebase a branch I'd like to decide when it
is done.
So this point - is automerge necessary or not - is a large portion of
what prompted Sam's original e-mail. In exploring git and our existing
workflow, the automerge script itself turned out to be rather tricky.
As he pointed out in his first comment, merely re-building the history
from the various automerge properties has some complexity. The
automerge script has its own complexities - should we be automatically
rebasing branches? Should it instead cherry-pick commits? Neither
option is terribly attractive, for different reasons.
My inclination is that we won't know if we really need a git version
of the automerge script until we've used git for awhile. I suspect
that you are right, and that manually rebasing a branch is not much
additional work (if any) over what is already required when using
automerge.
I'd propose that, at the very least, we ignore the automerge script
portion of team branches until we know if we need it.
If people haven't tried my faux asterisk-testsuite git repo yet, I
would highly recommend doing so. It would give you an example use
case for the 'automerge' script. Since you are using gerrit (\o/) it
has the ability to merge code into branches. However, there are some
issues gerrit does not take into account.
One of the way OpenStack Ci works around it, basically there is a
merge working branch (code in review) into master branch job that
fires each time. If successful, the tests continue to run, if it
fails, then gerrit gives a -1 right away and no tests are executed.
Doing the same would be recommended. It would be up to the developer
to away rebase against master then repost their code for review.
Then, when it comes time to merge the code, again there is a merge job
that fires, all tests are rerun and then gerrit eventually merges the
code into master.
--
Paul Belanger | PolyBeacon, Inc.
Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode)
Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger
--
_
-- 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] git migration update
On Mon, Dec 22, 2014 at 9:01 PM, Tzafrir Cohen tzafrir.co...@xorcom.com wrote:
Hi,
Thanks for the update.
On Mon, Dec 22, 2014 at 01:03:17PM -0600, Samuel Galarneau wrote:
Just wanted to update everyone on the git migration status and illicit some
feedback on a few items.
We setup an instance of Gerrit and Jenkins internally, imported the
Asterisk testsuite into a git repo, and configured Gerrit and Jenkins
together.
Just a note: currently we have two pending reviews of patches by
private mails in dahdi: one in dahdi-linux and one in dahdi-tools. I
wonder when we can start using Gerrit.
2 - we have a few options as far as team branches go. We could configure
user branches using refs/heads/team/${username}/* permissions in Gerrit to
allow users to create branches. This would prohibit other users from
pushing to a user branch, but they would still be visible. This would most
likely involve reproducing some sort of automerge/autorebase process. The
other option is to use github as another remote for team branches, with a
remote pointing to Gerrit for code reviews. Is there a preference between
these two approaches, or perhaps a better setup we could follow?
What if I have my own git server (which is not github)?
But then again, why are team branches needed? When I work on my own
branch I keep it in sync with the main development branch manually. If I
don't work on it, it will fall back, but merging the changes (or
rebasing) should be easy with git. And if I want to work on someone
else's branch I can do this sync on my own.
I don't think I'd want automerge. Autorebase is probably bad as you
can't clone that branch. If I rebase a branch I'd like to decide when it
is done.
So this point - is automerge necessary or not - is a large portion of
what prompted Sam's original e-mail. In exploring git and our existing
workflow, the automerge script itself turned out to be rather tricky.
As he pointed out in his first comment, merely re-building the history
from the various automerge properties has some complexity. The
automerge script has its own complexities - should we be automatically
rebasing branches? Should it instead cherry-pick commits? Neither
option is terribly attractive, for different reasons.
My inclination is that we won't know if we really need a git version
of the automerge script until we've used git for awhile. I suspect
that you are right, and that manually rebasing a branch is not much
additional work (if any) over what is already required when using
automerge.
I'd propose that, at the very least, we ignore the automerge script
portion of team branches until we know if we need it.
--
Matthew Jordan
Digium, Inc. | Engineering Manager
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] git migration update
On Wed, Dec 24, 2014 at 4:23 PM, Russell Bryant russ...@russellbryant.net wrote: On Wed, Dec 24, 2014 at 5:06 PM, Olle E. Johansson o...@edvina.net wrote: You are missing one thing. When committing to the current team branches, the code is contributed under the license agreement. The code in my branches is available for Digium to use at any point in time. If I had to have it in my own GIT or github it would be very different. Certainly feature branches could be created in the main repo on a case by case basis as it makes sense. I think the main point is that in a git world, people have no use for pushing their dev branches into the main repo. It's just a different model. I don't see why anyone would use them for day-to-day work like team branches have been used in the past. Licensing is a good point. Code contributions that are licensed back to the Asterisk project via the CLA require the author to acknowledge in some fashion that they are the author of the patch, and that they have the right to grant to Digium a license to the submission. Currently, we've found two ways to make sure that a submission is licensed in some fashion: * Require the author to put the patch on an issue in JIRA * Have the author submit the patch for peer review on Review Board In both cases, the user account is verified to have submitted a CLA (via some backend magic-ry), and the act of them submitting the patch in either form constitutes an implicit acknowledgement on their part that they are abiding by the CLA. Enforcement of all of this is admittedly somewhat best effort - that is, it is up to the author of the submission to verify that they are doing the right thing. Technically, for example, someone with SVN commit access could commit anything to their existing team SVN branches, and could - I suppose - even claim that something that they committed to the SVN branch was not licensed back to Digium or the project. That would be rather mean of them, however :-) From that perspective, I think we can split up the existing team branches into two use cases. Use Case #1: I want a place to put my own personal work that I plan to push to the mainline branches in the short to medium term In this particular case, team branches are certainly not strictly necessary. Collaboration could happen through any git server (such as Github), and the act of pushing the contribution to the project's git server/Gerrit would constitute the contribution. The user account associated with the push will still be checked for a CLA, etc. Team branches *may* be useful, particularly if the work is a large collaborative effort and will not be pushed to a mainline branch in the short term - such as the pimp_my_sip work for Asterisk 12 or the media format work for Asterisk 13. In that case, it may be useful to have branches similar to the existing /team/group branches. In those cases, a single person was typically still used as the merge maintainer, that is, the target of the 'automerge-email' property. Requiring manual rebasing does not feel too onerous. Use Case #2: I want a place to put work that I am ready to license but not ready to push to the mainline branches but that I want available In this particular case, if you want the licensing picture to be clear but you are not yet ready to push to the mainline branches, then a team branch on the same git repo is certainly useful, as we can associate the push to the team branch with your user account, which has a CLA. Given what is currently set up on git.asterisk.org, it feels like there should be a way to make this happen without too much effort. What _does_ fall away in both of these use cases is the concept of 'private' team branches. In those cases, it feels like having a separate git server is a better answer, and requiring the maintainers of those git servers to rebase as they feel necessary. Whether or not this ends up necessitating some automerge like script is really up to the maintainers of those private branches. -- Matthew Jordan Digium, Inc. | Engineering Manager 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] git migration update
On 23 Dec 2014, at 21:53, Paul Belanger paul.belan...@polybeacon.com wrote:
On Tue, Dec 23, 2014 at 7:20 AM, Leif Madsen lmad...@thinkingphones.com
wrote:
On 22 December 2014 at 18:34, Russell Bryant russ...@russellbryant.net
wrote:
On Mon, Dec 22, 2014 at 3:08 PM, George Joseph
george.jos...@fairview5.com wrote:
On Mon, Dec 22, 2014 at 12:03 PM, Samuel Galarneau
sgalarn...@digium.com wrote:
2 - we have a few options as far as team branches go. We could configure
user branches using refs/heads/team/${username}/* permissions in Gerrit to
allow users to create branches. This would prohibit other users from
pushing
to a user branch, but they would still be visible. This would most likely
involve reproducing some sort of automerge/autorebase process. The other
option is to use github as another remote for team branches, with a remote
pointing to Gerrit for code reviews. Is there a preference between these
two
approaches, or perhaps a better setup we could follow?
I don't think there's any need for you to host users' repos any more.
It may have made sense for SVN but I don't think it does for GIT. Let
users
make their own arrangements be it GitHub or in my case, my own GIT
infrastructure.
+1. I don't think it makes sense with git. github or whatever should
work just fine for that purpose.
Another +1 here. The beautiful thing about git is that you're not going to
need to do that. Anyone can use whatever git method they want (local,
github, stash, etc) and just rebase against the origin branch with a remote.
If people want to work together, then there are various ways of doing that,
one of which github makes incredibly straight forward.
I agree with everything everybody has said about team branches. They
are no longer needed server side for collaboration.
You are missing one thing. When committing to the current team branches,
the code is contributed under the license agreement.
The code in my branches is available for Digium to use at any point in
time. If I had to have it in my own GIT or github it would be very different.
/O
--
_
-- 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] git migration update
On Wed, Dec 24, 2014 at 5:06 PM, Olle E. Johansson o...@edvina.net wrote: You are missing one thing. When committing to the current team branches, the code is contributed under the license agreement. The code in my branches is available for Digium to use at any point in time. If I had to have it in my own GIT or github it would be very different. Certainly feature branches could be created in the main repo on a case by case basis as it makes sense. I think the main point is that in a git world, people have no use for pushing their dev branches into the main repo. It's just a different model. I don't see why anyone would use them for day-to-day work like team branches have been used in the past. -- 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
Re: [asterisk-dev] git migration update
On 22 December 2014 at 18:34, Russell Bryant russ...@russellbryant.net
wrote:
On Mon, Dec 22, 2014 at 3:08 PM, George Joseph
george.jos...@fairview5.com wrote:
On Mon, Dec 22, 2014 at 12:03 PM, Samuel Galarneau sgalarn...@digium.com
wrote:
2 - we have a few options as far as team branches go. We could configure
user branches using refs/heads/team/${username}/* permissions in Gerrit to
allow users to create branches. This would prohibit other users from
pushing to a user branch, but they would still be visible. This would most
likely involve reproducing some sort of automerge/autorebase process. The
other option is to use github as another remote for team branches, with a
remote pointing to Gerrit for code reviews. Is there a preference between
these two approaches, or perhaps a better setup we could follow?
I don't think there's any need for you to host users' repos any more.
It may have made sense for SVN but I don't think it does for GIT. Let
users make their own arrangements be it GitHub or in my case, my own GIT
infrastructure.
+1. I don't think it makes sense with git. github or whatever should
work just fine for that purpose.
Another +1 here. The beautiful thing about git is that you're not going to
need to do that. Anyone can use whatever git method they want (local,
github, stash, etc) and just rebase against the origin branch with a
remote. If people want to work together, then there are various ways of
doing that, one of which github makes incredibly straight forward.
--
Leif Madsen
--
_
-- 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] git migration update
On Tue, Dec 23, 2014 at 7:20 AM, Leif Madsen lmad...@thinkingphones.com wrote:
On 22 December 2014 at 18:34, Russell Bryant russ...@russellbryant.net
wrote:
On Mon, Dec 22, 2014 at 3:08 PM, George Joseph
george.jos...@fairview5.com wrote:
On Mon, Dec 22, 2014 at 12:03 PM, Samuel Galarneau
sgalarn...@digium.com wrote:
2 - we have a few options as far as team branches go. We could configure
user branches using refs/heads/team/${username}/* permissions in Gerrit to
allow users to create branches. This would prohibit other users from
pushing
to a user branch, but they would still be visible. This would most likely
involve reproducing some sort of automerge/autorebase process. The other
option is to use github as another remote for team branches, with a remote
pointing to Gerrit for code reviews. Is there a preference between these
two
approaches, or perhaps a better setup we could follow?
I don't think there's any need for you to host users' repos any more.
It may have made sense for SVN but I don't think it does for GIT. Let users
make their own arrangements be it GitHub or in my case, my own GIT
infrastructure.
+1. I don't think it makes sense with git. github or whatever should
work just fine for that purpose.
Another +1 here. The beautiful thing about git is that you're not going to
need to do that. Anyone can use whatever git method they want (local,
github, stash, etc) and just rebase against the origin branch with a remote.
If people want to work together, then there are various ways of doing that,
one of which github makes incredibly straight forward.
I agree with everything everybody has said about team branches. They
are no longer needed server side for collaboration.
--
Paul Belanger | PolyBeacon, Inc.
Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode)
Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger
--
_
-- 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] git migration update
On Mon, Dec 22, 2014 at 12:03 PM, Samuel Galarneau sgalarn...@digium.com
wrote:
Just wanted to update everyone on the git migration status and illicit
some feedback on a few items.
We setup an instance of Gerrit and Jenkins internally, imported the
Asterisk testsuite into a git repo, and configured Gerrit and Jenkins
together.
A few issues and questions have come up in the course of setting this all
up:
1 - merge history from svn has not been preserved, primarily due to the
fact that we are missing svn:mergeinfo properties in our svn repo. The
current plan is to use the various custom svn properties we do have along
with log messages (the one I've looked at all appear to mention which
rev(s) were merged in a given merge commit) to build a graft file and using
git filter-branch to rebuild the merge history. Has anyone else run into
this issue? Are there better ways to handle this?
2 - we have a few options as far as team branches go. We could configure
user branches using refs/heads/team/${username}/* permissions in Gerrit to
allow users to create branches. This would prohibit other users from
pushing to a user branch, but they would still be visible. This would most
likely involve reproducing some sort of automerge/autorebase process. The
other option is to use github as another remote for team branches, with a
remote pointing to Gerrit for code reviews. Is there a preference between
these two approaches, or perhaps a better setup we could follow?
I don't think there's any need for you to host users' repos any more. It
may have made sense for SVN but I don't think it does for GIT. Let users
make their own arrangements be it GitHub or in my case, my own GIT
infrastructure.
Any input is welcome. Ultimately we want the process of contributing to
Asterisk to be better than it is now so we need your support in determining
what the best way forward is.
--
Samuel Fortier-Galarneau
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: www.digium.com www.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
Re: [asterisk-dev] git migration update
On Mon, Dec 22, 2014 at 3:08 PM, George Joseph george.jos...@fairview5.com
wrote:
On Mon, Dec 22, 2014 at 12:03 PM, Samuel Galarneau sgalarn...@digium.com
wrote:
2 - we have a few options as far as team branches go. We could configure
user branches using refs/heads/team/${username}/* permissions in Gerrit to
allow users to create branches. This would prohibit other users from
pushing to a user branch, but they would still be visible. This would most
likely involve reproducing some sort of automerge/autorebase process. The
other option is to use github as another remote for team branches, with a
remote pointing to Gerrit for code reviews. Is there a preference between
these two approaches, or perhaps a better setup we could follow?
I don't think there's any need for you to host users' repos any more. It
may have made sense for SVN but I don't think it does for GIT. Let users
make their own arrangements be it GitHub or in my case, my own GIT
infrastructure.
+1. I don't think it makes sense with git. github or whatever should work
just fine for that purpose.
--
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
Re: [asterisk-dev] git migration update
Hi,
Thanks for the update.
On Mon, Dec 22, 2014 at 01:03:17PM -0600, Samuel Galarneau wrote:
Just wanted to update everyone on the git migration status and illicit some
feedback on a few items.
We setup an instance of Gerrit and Jenkins internally, imported the
Asterisk testsuite into a git repo, and configured Gerrit and Jenkins
together.
Just a note: currently we have two pending reviews of patches by
private mails in dahdi: one in dahdi-linux and one in dahdi-tools. I
wonder when we can start using Gerrit.
2 - we have a few options as far as team branches go. We could configure
user branches using refs/heads/team/${username}/* permissions in Gerrit to
allow users to create branches. This would prohibit other users from
pushing to a user branch, but they would still be visible. This would most
likely involve reproducing some sort of automerge/autorebase process. The
other option is to use github as another remote for team branches, with a
remote pointing to Gerrit for code reviews. Is there a preference between
these two approaches, or perhaps a better setup we could follow?
What if I have my own git server (which is not github)?
But then again, why are team branches needed? When I work on my own
branch I keep it in sync with the main development branch manually. If I
don't work on it, it will fall back, but merging the changes (or
rebasing) should be easy with git. And if I want to work on someone
else's branch I can do this sync on my own.
I don't think I'd want automerge. Autorebase is probably bad as you
can't clone that branch. If I rebase a branch I'd like to decide when it
is done.
--
Tzafrir Cohen
icq#16849755 jabber:tzafrir.co...@xorcom.com
+972-50-7952406 mailto:tzafrir.co...@xorcom.com
http://www.xorcom.com
--
_
-- 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] git migration update
+1 from me as well.
We use the methodology of using personalized repos for projects and it
works really well. We use either GitHub
or BitBucket, depending on the project - but both work equally well.
I'm confident that Atlassian will be happy to show their support by
contributing a Stash license to the project,
and you'll get the same functionality of BitBucket on a dedicated server -
if you don't want to host the project
publicly.
On Tue, Dec 23, 2014 at 1:34 AM, Russell Bryant russ...@russellbryant.net
wrote:
On Mon, Dec 22, 2014 at 3:08 PM, George Joseph
george.jos...@fairview5.com wrote:
On Mon, Dec 22, 2014 at 12:03 PM, Samuel Galarneau sgalarn...@digium.com
wrote:
2 - we have a few options as far as team branches go. We could configure
user branches using refs/heads/team/${username}/* permissions in Gerrit to
allow users to create branches. This would prohibit other users from
pushing to a user branch, but they would still be visible. This would most
likely involve reproducing some sort of automerge/autorebase process. The
other option is to use github as another remote for team branches, with a
remote pointing to Gerrit for code reviews. Is there a preference between
these two approaches, or perhaps a better setup we could follow?
I don't think there's any need for you to host users' repos any more.
It may have made sense for SVN but I don't think it does for GIT. Let
users make their own arrangements be it GitHub or in my case, my own GIT
infrastructure.
+1. I don't think it makes sense with git. github or whatever should
work just fine for that purpose.
--
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
--
_
-- 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
