On Tue, Aug 9, 2011 at 1:01 PM, Dan Prince <dan.pri...@rackspace.com> wrote: > Couple of comments: > > 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?
Actually, this is being worked on: https://bugs.launchpad.net/openstack-ci/+bug/823173 > 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? Also being worked on, by the Nokia team and should be in the next release of Gerrit: I think this is the feature issue: http://code.google.com/p/gerrit/issues/detail?id=106 That being said, after using the "next changed source file" links, I've actually changed my mind about using a single diff for larger commits with lots of files changed. Sometimes it's actually nice to scroll through them. But, having the option to have a single page diff would be useful at times, too... > 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. I will let Jim and Monty talk about this. > 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. I explained the deficiencies in GitHub's pull request system for integration with an automated patch queue manager and gated trunk. Could you point to a review you've done in Gerrit so far that we can use as a starting point for discussion on what improvements can be made relative to the "GitHub process"? I couldn't find any reviews that you've done in Gerrit. Thanks, jay > Dan > > > > -----Original Message----- > From: "Jay Pipes" <jaypi...@gmail.com> > Sent: Monday, August 8, 2011 2:50pm > To: openstack@lists.launchpad.net > Subject: [Openstack] Status of Git/Gerrit Code Hosting/Review > > Hello all, > > tl;dr > ======= > > Contributors have been giving Monty Taylor and Jim Blair feedback on > the Gerrit code review system over the last few weeks. Both the > Keystone and Glance projects have now migrated to using Git as their > source control system and Gerrit for code review and integration into > the Jenkins continuous integration system. > > Tomorrow, the Project Policy Board (PPB) will be voting on two things: > > 1) Should OS projects > a) have a vetted set of options for hosting and review, or > b) be required to use a single toolset for review and hosting > 2) Shall Gerrit+Git be included in the set of vetted options or be the > single option (dependent on the vote result for 1) above) > > Feedback on #2 is most welcome. Please feel free to respond to this > email, catch us on IRC or email me directly. > > Links: > > Working with Gerrit: http://wiki.openstack.org/GerritWorkflow > Code Review in Gerrit: http://review.openstack.org > > Details > ======= > > Over the last few weeks, Monty Taylor and Jim Blair have been working > with a number of OpenStack contributors to gather feedback on a > Git-based development workflow, toolset, and review process. > > First, Monty and Jim investigated whether GitHub's pull request system > would be sufficient to enforce existing code review and approval > policies. It was determined that GitHub's pull request system was not > sufficient. The main reason why the pull request system failed to meet > needs is that there is no overall way to track the current state of a > given pull request. While this is fine for the simple case (merge > request is accepted and merged) it starts to fall over with some of > the more complex back and forths that we wind up having in many > OpenStack projects. Additionally, this assessment was predicated on > the current design of a gated trunk with an automated patch queue > manager, and a system where a developer is not required to spend time > landing a patch (other than potential needs for rebases or changes due > to code review). > > Monty and Jim then decided to set up a Gerrit server for code review > and CI integration at http://review.openstack.org. Gerrit is a tool > developed by Google to address some of the functionality the Android > Open Source team needed around automated patch queue management and > code reviews. > > The first project that moved from Launchpad to Gerrit/Git was the > openstack-ci project. This is the glue code and scripts that support > the continuous integration environment running on > http://jenkins.openstack.org. > > After gaining some experience with Gerrit through the migration of > this project from Launchpad, the next OpenStack subproject to move to > the Gerrit platform was the Keystone incubated project. Keystone was > already using git for source control and was on GitHub, using GitHub's > Issues for its pull requests and bug tracking. However, the Keystone > source code was not gated by a non-human patch queue management > system; a Keystone developer would manually merge proposed branches > into the master Keystone source tree, and code reviews were not passed > through any automated tests on http://jenkins.openstack.org. Monty and > Jim worked with Dolph, Yogi, Ziad, and other Keystone developers to > get their code reviews done via Gerrit and get their unit and > functional tests running on each commit through Jenkins. There were a > few hiccups along the way, but the hiccups served as valuable lessons > and were documented in the workflow wiki page > http://wiki.openstack.org/GerritWorkflow. > > Last Thursday morning, the Glance project was migrated from Bazaar and > Launchpad code hosting to use Git and Gerrit. The migration went > pretty smoothly, and a number of Glance developers have already been > proposing, reviewing, and approving code via Gerrit. Launchpad is used > for all bug tracking and blueprint management, still, but the code at > http://code.launchpad.net/glance is merely a read-only mirror of the > git repository. > > Outstanding Issues/Questions > ===================== > > 1) John Dickinson and Chuck Thier raised the question that if Gerrit > is going to be the (or one of the) proposed code review and patch > management system, that hosting Git repositories on GitHub might be > confusing for GitHub users, since most would expect to use pull > requests to merge their own code back into the project's master repo. > This is a valid concern and Monty and Jim are investigating > establishing a GitWeb or Gitorious server on http://git.openstack.org > that would serve as the canonical Git repo locations for OpenStack > projects instead of GitHub. This would be similar to how > http://git.kernel.org works > > 2) Only code hosting has been moved to Git/Gerrit. There are currently > no plans to discuss moving bug tracking for existing OpenStack core > projects to GitHub Issues. Gerrit is fully integrated with Launchpad > bug tracking. This means that Gerrit *will close* (mark Fix Committed) > Launchpad bugs if you include bug text in your commit message. > > 3) The user interface for Gerrit is UGLY. I don't think anyone would > disagree with that. :) That said, Gerrit's UI can be modified via CSS > and templates without having to keep a separate fork of Gerrit. If you > are interested in helping Monty and Jim make the Gerrit UI prettier > and saving reviewers eyeballs, please do contact me. > > Cheers, > -jay > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > This email may include confidential information. If you received it in > error, please delete it. > > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp