On Tue, Sep 16, 2014 at 6:01 PM, Russell Bryant <[email protected]> wrote: > On Tue, Sep 16, 2014 at 3:48 PM, Matthew Jordan <[email protected]> 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: [email protected] | 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
