← Back to team overview

openstack team mailing list archive

Re: Status of Git/Gerrit Code Hosting/Review

 

On Tue, Aug 9, 2011 at 9:55 PM, Dan Prince <dan.prince@xxxxxxxxxxxxx> wrote:
> To be honest I was a Git user first. I love Git. Its great. A big part of
> that for me though is GitHub.

Yes, you and a number of others. :)

> Since we have figured out that GitHub isn't going to work for the project at
> this time I'm wondering how many others feel like just using Git (no GitHub)
> is worth ditching the all-in-one feature set we have on LP.

That's actually not what we've figured out. What we did determine is
that GitHub's pull requests system does not have the granularity
necessary in its status to facilitate a gated trunk the way we are
looking for. Gerrit provides that. GitHub can still provide the code
hosting and in the future, there may even be some integration work
that will make the GitHub pull request system more fluidly interact
with Gerrit.

> Look. Jay's initial email on this thread was about whether we should require
> all projects to use one VCS over another.

At the risk of sounding like a complete downer, that's actually not
what my post said. :) What I said was that the *PPB* was going to be
voting on whether all projects should use a single toolset or a set of
vetted toolsets, and that pursuant to the decision reached there,
whether Gerrit/GitHub would be part of either the single toolset or
the set of vetted options. I asked for community feedback on the
Gerrit/GitHub environment that had already been established and in use
by the Glance and Keystone projects.

> I say put it to a vote. We have
> all the polling setup for governance stuff. Why not send out a survey and
> ask the developers (those who have committed code) what they prefer?

I recognize that this issue is divisive and that numerous parties have
strong, deeply-held opinions about tooling. That said, this particular
issue is the purview of the 12-member Project Policy Board, and it is
the votes of the PPB that determined this particular decision today.

The decision of the PPB, by a vote of 7 to 5 today, was that there
shall be a single toolset that will be used by all core OpenStack
projects.

Furthermore, it was decided by a vote of 11 - 0 with 1 abstaining that
the single toolset shall be:

 * Code on GitHub
 * Code Review on Gerrit
 * Bug tracking, release management, packaging, blueprints to stay on Launchpad

After that, there was a unanimous vote that Nova and Swift shall move
to the above recommended toolset before the Essex design summit.

For all the gory details, feel free to peruse the oft-entertaining PPB
meeting log: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-08-09-20.00.log.html

Cheers,
jay

> -----Original Message-----
> From: "Monty Taylor" <mordred@xxxxxxxxxxxx>
> Sent: Tuesday, August 9, 2011 2:29pm
> To: "Jay Pipes" <jaypipes@xxxxxxxxx>
> Cc: "Dan Prince" <dan.prince@xxxxxxxxxxxxx>, openstack@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Openstack] Status of Git/Gerrit Code Hosting/Review
>
>
>>> 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 certainly don't want anyone to feel duped here. We did start down the
> road quite earnestly of using github, and could not meet all of the
> requirements that we have currently as a project. At that point, we
> moved on to attempt to solve the underlying problem that people had
> expressed in the best way possible - which I'm sure you can understand
> given the large number of people with conflicting interests was ... fun.
>
> In looking at things - it seemed that, to be quite honest, the number
> one single change that would make the maximum number of people happy was
> switching from bzr to git, and there was nothing about git that would
> not meet the needs of the project. (it is, of course, an excellent tool)
>
> All in all, I'm not saying that all of the design choices are perfect,
> and there are certainly things to work on - but I _do_ think that we're
> in an excellent position now to actually effect the changes that we
> need. (which will make it more effective to sit down at design summits
> and discuss needs - since we should be able to actually implement them)
>
> Thanks!
> Monty
>
>>> -----Original Message-----
>>> From: "Jay Pipes" <jaypipes@xxxxxxxxx>
>>> Sent: Monday, August 8, 2011 2:50pm
>>> To: openstack@xxxxxxxxxxxxxxxxxxx
>>> 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@xxxxxxxxxxxxxxxxxxx
>>> 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@xxxxxxxxxxxxxxxxxxx
>> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>


References