<font face="arial" size="2"><p style="font-family: arial; font-size: 10pt;">Hi Jay,</p>
<p style="font-family: arial; font-size: 10pt;"> </p>
<p><span style="font-family: arial; font-size: 10pt;">Definitely appreciate all the hard work Monty and Jim have put into the migration. This is a lot of work for sure.</span></p>
<p> </p>
<p><span style="font-family: arial; font-size: 10pt;">Couple of comments:</span></p>
<p> </p>
<p><span style="font-family: arial; font-size: 10pt;">1) While gerrit is integrated w/ Launchpad (and can close tickets) Launchpad is not integrated with Gerrit. Things like referencing a branch from within a ticket or blueprint aren't going to work as well as they used to right?</span></p>
<p> </p>
<p><span style="font-family: arial; font-size: 10pt;">2) I'd like to see a unified diff containing all the files on the Gerrit review pages. Is there a way to do this or am I missing something?</span></p>
<p> </p>
<p><span style="font-family: arial; font-size: 10pt;">3) The branch/refspec names Gerrit uses are not very user friendly. In Launchpad we typically had people naming their branches w/ either a feature/fix name or the ticket number. So in Launchpad my branch would be called something like 'lp:~dan-prince/fix_ec2_metadata' or whatever. In Gerrit the branch names up for review are rather cryptic 'refs/changes/76/176/1' which means that when trying to track and Gate branches before they hit trunk we are going to manually have to do an extra bit of detective work to make sense of which tickets and features a particular refspec corresponds to. Some extra tooling might might this easier but I really dislike that we have no control over the branch names that are up for review.</span></p>
<p> </p>
<p><span style="font-family: arial; font-size: 10pt;">Lastly I kind of feel like we've bee dupped. When we talked about Git code hosting on GitHub at the conference some of the major points were improved code review (on GitHub) and performance improvements for checkouts, etc. While we may have taken a step forward on the performance front IMHO we've taken a major step backwards as far as the review and tracking process goes.</span></p>
<p> </p>
<p><span style="font-family: arial; font-size: 10pt;">Dan</span></p>
<p style="font-family: arial; font-size: 10pt;"> </p>
<p style="font-family: arial; font-size: 10pt;">-----Original Message-----<br />From: "Jay Pipes" <jaypipes@gmail.com><br />Sent: Monday, August 8, 2011 2:50pm<br />To: openstack@lists.launchpad.net<br />Subject: [Openstack] Status of Git/Gerrit Code Hosting/Review<br /><br /></p>
<div id="SafeStyles1312908663" style="font-family: arial; font-size: 10pt;">
<p>Hello all,<br /><br />tl;dr<br />=======<br /><br />Contributors have been giving Monty Taylor and Jim Blair feedback on<br />the Gerrit code review system over the last few weeks. Both the<br />Keystone and Glance projects have now migrated to using Git as their<br />source control system and Gerrit for code review and integration into<br />the Jenkins continuous integration system.<br /><br />Tomorrow, the Project Policy Board (PPB) will be voting on two things:<br /><br />1) Should OS projects<br /> a) have a vetted set of options for hosting and review, or<br /> b) be required to use a single toolset for review and hosting<br />2) Shall Gerrit+Git be included in the set of vetted options or be the<br />single option (dependent on the vote result for 1) above)<br /><br />Feedback on #2 is most welcome. Please feel free to respond to this<br />email, catch us on IRC or email me directly.<br /><br />Links:<br /><br />Working with Gerrit: http://wiki.openstack.org/GerritWorkflow<br />Code Review in Gerrit: http://review.openstack.org<br /><br />Details<br />=======<br /><br />Over the last few weeks, Monty Taylor and Jim Blair have been working<br />with a number of OpenStack contributors to gather feedback on a<br />Git-based development workflow, toolset, and review process.<br /><br />First, Monty and Jim investigated whether GitHub's pull request system<br />would be sufficient to enforce existing code review and approval<br />policies. It was determined that GitHub's pull request system was not<br />sufficient. The main reason why the pull request system failed to meet<br />needs is that there is no overall way to track the current state of a<br />given pull request. While this is fine for the simple case (merge<br />request is accepted and merged) it starts to fall over with some of<br />the more complex back and forths that we wind up having in many<br />OpenStack projects. Additionally, this assessment was predicated on<br />the current design of a gated trunk with an automated patch queue<br />manager, and a system where a developer is not required to spend time<br />landing a patch (other than potential needs for rebases or changes due<br />to code review).<br /><br />Monty and Jim then decided to set up a Gerrit server for code review<br />and CI integration at http://review.openstack.org. Gerrit is a tool<br />developed by Google to address some of the functionality the Android<br />Open Source team needed around automated patch queue management and<br />code reviews.<br /><br />The first project that moved from Launchpad to Gerrit/Git was the<br />openstack-ci project. This is the glue code and scripts that support<br />the continuous integration environment running on<br />http://jenkins.openstack.org.<br /><br />After gaining some experience with Gerrit through the migration of<br />this project from Launchpad, the next OpenStack subproject to move to<br />the Gerrit platform was the Keystone incubated project. Keystone was<br />already using git for source control and was on GitHub, using GitHub's<br />Issues for its pull requests and bug tracking. However, the Keystone<br />source code was not gated by a non-human patch queue management<br />system; a Keystone developer would manually merge proposed branches<br />into the master Keystone source tree, and code reviews were not passed<br />through any automated tests on http://jenkins.openstack.org. Monty and<br />Jim worked with Dolph, Yogi, Ziad, and other Keystone developers to<br />get their code reviews done via Gerrit and get their unit and<br />functional tests running on each commit through Jenkins. There were a<br />few hiccups along the way, but the hiccups served as valuable lessons<br />and were documented in the workflow wiki page<br />http://wiki.openstack.org/GerritWorkflow.<br /><br />Last Thursday morning, the Glance project was migrated from Bazaar and<br />Launchpad code hosting to use Git and Gerrit. The migration went<br />pretty smoothly, and a number of Glance developers have already been<br />proposing, reviewing, and approving code via Gerrit. Launchpad is used<br />for all bug tracking and blueprint management, still, but the code at<br />http://code.launchpad.net/glance is merely a read-only mirror of the<br />git repository.<br /><br />Outstanding Issues/Questions<br />=====================<br /><br />1) John Dickinson and Chuck Thier raised the question that if Gerrit<br />is going to be the (or one of the) proposed code review and patch<br />management system, that hosting Git repositories on GitHub might be<br />confusing for GitHub users, since most would expect to use pull<br />requests to merge their own code back into the project's master repo.<br />This is a valid concern and Monty and Jim are investigating<br />establishing a GitWeb or Gitorious server on http://git.openstack.org<br />that would serve as the canonical Git repo locations for OpenStack<br />projects instead of GitHub. This would be similar to how<br />http://git.kernel.org works<br /><br />2) Only code hosting has been moved to Git/Gerrit. There are currently<br />no plans to discuss moving bug tracking for existing OpenStack core<br />projects to GitHub Issues. Gerrit is fully integrated with Launchpad<br />bug tracking. This means that Gerrit *will close* (mark Fix Committed)<br />Launchpad bugs if you include bug text in your commit message.<br /><br />3) The user interface for Gerrit is UGLY. I don't think anyone would<br />disagree with that. :) That said, Gerrit's UI can be modified via CSS<br />and templates without having to keep a separate fork of Gerrit. If you<br />are interested in helping Monty and Jim make the Gerrit UI prettier<br />and saving reviewers eyeballs, please do contact me.<br /><br />Cheers,<br />-jay<br /><br />_______________________________________________<br />Mailing list: https://launchpad.net/~openstack<br />Post to : openstack@lists.launchpad.net<br />Unsubscribe : https://launchpad.net/~openstack<br />More help : https://help.launchpad.net/ListHelp<br />This email may include confidential information. If you received it in error, please delete it.<br /><br /></p>
</div></font>