[asterisk-dev] git migration update

Matthew Jordan mjordan at digium.com
Mon Dec 29 09:07:21 CST 2014


On Wed, Dec 24, 2014 at 4:23 PM, Russell Bryant
<russell at russellbryant.net> wrote:
> On Wed, Dec 24, 2014 at 5:06 PM, Olle E. Johansson <oej at 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



More information about the asterisk-dev mailing list