[asterisk-dev] Git Migration

[Paul Belanger]

On Tue, Sep 16, 2014 at 6:01 PM, Russell Bryant
<russell at russellbryant.net> wrote:
> On Tue, Sep 16, 2014 at 3:48 PM, Matthew Jordan <mjordan at digium.com> wrote:
>>
>> "And there was much rejoicing"
>
>
> \o/
>
>>
>> But seriously, we all know that a lot of people have wanted to move to Git
>> for some time. For the record, everyone at Digium has wanted to move the
>> project to Git for some time. I swore to myself that we wouldn't do another
>> Standard release on Subversion - after we spent at least six weeks mucking
>> around with merge conflicts during Asterisk 12 - and with Asterisk 14
>> looming ever closer, the time is now to start getting something done on
>> this.
>>
>> So!
>>
>> To that end, a page on the wiki has been made with some initial thoughts:
>>
>> https://wiki.asterisk.org/wiki/display/AST/Git+Migration
>>
>> To summarize:
>>  * A comparison of management platforms has been done. Barring a giant
>> catastrophe or some insane limitation, we're going to go simple here and
>> stick with gitolite. Reasoning is on the wiki page.
>>  * The first thing to migrate is _not_ the Asterisk project, but the
>> Asterisk Test Suite. That will allow us (or force us) to deal with some of
>> the tooling and process issues, which will make it easier to tackle
>> Asterisk.
>>
>> I'm sure there are a lot of opinions about all of this, and if you have
>> thoughts on technical or process hurdles we may be running into, I'd love to
>> hear it. Just remember that like many other things in life and development,
>> there's a lot of ways to manage your source code. You may really, really,
>> _REALLY_ like the way Project X does it, and you may think that the way we
>> are proposing it is clearly inferior. That's great, you may be right. But in
>> the interest of this not dragging on for another 5 years, I'd like to keep
>> any discussions focussed on getting things done while not shooting ourselves
>> in our virtual feet.
>
>
> So, I realize this is pretty much exactly the opposite of what you just
> said, but I wanted to offer some comments on the infrastructure.  :-)  I'm
> really not deeply invested in what is chosen.  My interest here is just to
> provide an overview of another option in the interest of exploring options.
>
> For the last few years, most of my time has been going into OpenStack [1].
> We use git and I have become a big fan of our workflow and infrastructure.
> It's all open source and reusable.
>
> From a high level, all patches go to a code review system.  *Every* patch
> must be peer reviewed (usually by 2 people, but that's a policy decision).
> *Every* patch must also pass tests.  Once a patch passes both tests and peer
> review, it is automatically merged into the repository.
>
> I *love* that workflow for several reasons.  If it's appealing, it's
> probably much easier to do it now while you're doing a big switch anyway.
> If you're not sold, I'm certainly not hurt.  Like I said, I just wanted to
> offer info.  The current plan will be less up front setup for sure.
>
> If you're a hands on kind of person, browse http://review.openstack.org/ for
> open code reviews.  You can also see patches going through CI pipelines on
> http://status.openstack.org/zuul//
>
> The major tools involved are:
>
>  - gerrit for code review and repository management [2][3]
>  - jenkins for CI [4]
>  - Zuul, A CI job scheduler that automates running things in response to
> events on gerrit. [5]
>  - CGit, repo hosting [6][7]
>
> Everything we use is managed via puppet and all of the configuration is in
> git.  It's designed to be reusable.  The folks that run it have documented
> how to re-use it [8] and are quite friendly.  You can find them in
> #openstack-infra on freenode.
>
> [1] http://www.openstack.org
> [2] https://code.google.com/p/gerrit/
> [3] https://review.openstack.org/
> [4] http://jenkins-ci.org/
> [5] http://ci.openstack.org/zuul.html
> [6] http://ci.openstack.org/git.html
> [7] http://git.openstack.org
> [8] http://ci.openstack.org/running-your-own.html
>
> I'll also try to answer the fields of the comparison chart on the wiki page:
>
> -- Web View
>
> Yes.
>
> -- Project Management
>
> This would replace existing usage of bamboo and reviewboard.  It does not
> include issue tracking.  Keeping that is would be fine.
>
> -- Protected Branches
>
> Gerrit supports permissions on a per branch basis.
>
> -- Rewriting history
>
> Not sure the intent here ... wanting to make that can be avoided?
>
> In this system, the merges are automated so you can't accidentally do a bad
> push.  An admin can force reset a repo if needed, of course.
>
> -- Team repos
>
> I'd recommend just using your own account on github or whatever.
>
> -- Git hooks
>
> For what, exactly?  It's probably easier to discuss the problem that needs
> to be solved.
>
> -- Web hooks
>
> Again, it's probably worth discussing the use case.  Gerrit has an event
> stream.  That event stream includes merges.  Tools to do things in responses
> to merges (which could be running a web hook) listen and react.
>
> -- Performance
>
> Yes.  :-)
>
> There's lots of stats I could dig up, but as one example, I track code
> review stats for a subset of projects on review.openstack.org  In the last
> year, for that subset, there have been 266,127 code reviews done (avg > 700
> per day).  That gives some sense of scale.  From a quick glance at the CI
> status page (http://status.openstack.org/zuul/), it has been launching about
> 500-600 jobs per hour today.
>
> -- Process Recommendation
>
> I discussed this a good bit above, but I'm happy to answer questions.
>
Just to echo everything Russell typed, I also recommend above.  While
complicated and full of moving parts, its extremely good at what it
does.  I have a system running both public and private for different
projects I am doing.  One thing that is great about it, developers can
develop faster without knowing or understanding the release processes
of a project.

I think the issue that you'll run into the is amount of time and
effort to learn the system and understand the workings. I don't know
the official timelines, however if we are still talking about this at
Astricon, I don't mind sitting down with people and hashing it out.

Additionally, I'd offer up my public infrastructure for a demo or POC
of the asterisk testsuite.  Infact, once the project was converted
into git, it would only take a few minutes to import it into the
process.  The, people could do test commits / see how the system
works.

-- 
Paul Belanger | PolyBeacon, Inc.
Jabber: paul.belanger at polybeacon.com | IRC: pabelanger (Freenode)
Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger