openstack team mailing list archive

[Sandy Walsh <sandy.walsh@xxxxxxxxxxxxx>]

Thanks for the reply Monty.

The major argument I've heard to date about using something other than Gerrit is the effort gone into tying into the CI system. I buy those arguments and support not reinventing the wheel. Roundabout seemed like the logical point of integration for hubcap, but if there are other efforts that get us further for less work, I'm completely open to that.

All your issues about single state and status pages are what Hubcap intended to resolve.

The other arguments about parsing comments from github pull requests are less convincing to me than:
1. the error-prone Change-ID mechanism that Gerrit uses
2. the gerrit UI that opens 30 tabs when you want to do a review
3. the gerrit UI that loses your review data randomly
4. the environment variables you have to remember to set in each project
5. the 'git review' mechanism that prevents me from using 'git push' as expected.
6. the git dances that have to be performed when something goes wrong
7. the gerrit remotes that have to be set up that break your mental model of how git remotes work
8. complete re-votes required after a re-review (unless that was intentional?)

... and that's only from my first few days using Gerrit. 

Moreso, as was stated before, why are we even using github in this case? Why not just stand up a git server? 
Right now it feels like bubble-gum and binder twine.

We're talking simple string parsing here. The last keyword from a user is that users vote. Multiple pull requests would be equally easy to support with a !new_vote command (or some such thing).

I'm sure I'm missing some critical piece of data here. 

Thanks again,
Sandy



________________________________________
From: Monty Taylor [mordred@xxxxxxxxxxxx]
Sent: Tuesday, September 06, 2011 11:31 PM
To: Sandy Walsh
Cc: Stefano Maffulli; openstack@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Openstack] A possible alternative to Gerrit ...

Hi everybody!

I understand some of you are not comfortable with Gerrit and the
workflow I and others are working to implement. While this may be a
problem for some, it was never our intention to make life hard for
anybody here. Let me try to explain why and how we got to this decision
and make a proposal on how to move forward.

OpenStack is already a large project with tons of contributors, and it
aims to continue to be larger over time. This is one of the reasons for
all of the developer automation and controls that we put in back at the
very beginning - what works well for a team of 5 doesn't necessarily
work well for teams of 100+, especially when many of those 100+ may be
corporate contributors only hacking on the code because they are being
paid to. We have many corporate partners in this project, and over time
the number of devs that fit that profile is very likely going to increase.

The CI team led the analysis of a move to git and github and found
several deficiences in github pull requests, mainly in the area of
failure conditions and scale. They work GREAT for handling the simple
case, when they're just used as a basis for code reviews, or when every
thing works perfectly the first time. One major limitation, for example,
is that things get quickly complex when code needs to get re-reviewed as
part of normal process. Another is that github does not provide a
project-management oriented overview of pull request states.

With pull requests, it is impossible to see the current state of a
review, because there IS no current state of a review other than open or
closed. As far as we can tell, the general practice with pull requests
in this regard is to close the pull request on rejection and open a new
one when the review has been addressed and a new review is desired. The
problem with that is the loss of historical context for reviews. When
you have tons of reviewers and reviews, knowing that someone is just
fixing a review comment and that the entire change doesn't need to be
re-reviewed from scratch is helpful.  This feature is very important for
the Project Tech Leads.

We asked for months and months for conversations with github
about adding an overall status field and were told that the folks at
github were not interested in doing this.

A meta system can be hacked in to overload pull request comments in a
way that systems like roundabout can use, but this ends up again being
excellent for the simple case of approval or denial, but becomes baroque
when a pull request is sent back for review several times.

We couldn't find a convenient way to overcome this limitation without
adding complicated steps and extra knowledge for developers.

We looked at roundabout- quite strongly, in fact. It was, indeed, our
first choice when considering how to integrate github with our developer
systems. It's a great tool and I've recommended it to other people given
their workflow needs. However, in addition to the fact that it's based
on magical text in github pull request comments as I mentioned above, it
also does not have the level of jenkins integration that gerrit does.
The Gerrit Jenkins plugin (which is developed and maintained by the fine
folks at Nokia, but for which we've been developing patches to send
upstream) has deep hooks in to Jenkins. It can have jobs respond to the
gerrit event stream (no polling repos - stuff happens immediately) and
more importantly can converge/combine any jobs listening to the same
event as needing to all succeed. The sucess or failure of any of the
jobs is then reported back to the review in a sensible way - and the
workflow state transitions are quite clear. The two work in concert to
provide all of the change landing ability and flexibility we need moving
forward. Even better - it's an active project with an active upstream (a
combination of Google, Nokia and Qt no less) so we don't have to be in
the business of writing a custom CI integration piece.

Most importantly - we have had this conversation multiple times. We've
been discussing this publicly for months. We have addressed concerns
and enumerated the reasons why gerrit is technically superior given our
requirements.

We all know that nothing is perfect and we're all about change:
OpenStack is a big project and it's young. There will always be changes.
We've already changed our VCS after only one year. Anybody is of course
free to make his/her pitch for a different tool. Remember though that
every change doesn't come cheap and the cost needs to be justified in
front of tech leads and the hundreds of developers busy on the project.

With this many devs, there will NEVER (and I cannot stress that word
never enough is a textual email) be full agreement on developer tooling.
However, what we can do is take in the input of everyone's needs and do
our best to design a system that meets those needs in a way that serves
the project as a whole. That this inevitably means that the needs or
preferences of individual developers may not be stroked is merely a
given with a project of this size.

My suggestion is that folks send feedback on specific issues you have
with the current git/gerrit/jenkins setup and we'll be happy to do what
we can to address them.

Thanks!
Monty

On 09/05/2011 10:14 AM, Sandy Walsh wrote:
> Absolutely. It's a holiday here (I'm just checking in periodically).
>
> Enjoy your day y'all!
>
> -S
>
> ------------------------------------------------------------------------
> *From:* openstack-bounces+sandy.walsh=rackspace.com@xxxxxxxxxxxxxxxxxxx
> [openstack-bounces+sandy.walsh=rackspace.com@xxxxxxxxxxxxxxxxxxx] on
> behalf of Stefano Maffulli [smaffulli@xxxxxxxxx]
> *Sent:* Monday, September 05, 2011 12:35 PM
> *To:* openstack@xxxxxxxxxxxxxxxxxxx
> *Subject:* Re: [Openstack] A possible alternative to Gerrit ...
>
> 2011/9/5 Sandy Walsh <sandy.walsh@xxxxxxxxxxxxx
> <mailto:sandy.walsh@xxxxxxxxxxxxx>>
>
>     That said, whether we use roundabout or use the code that has
>     already been created for the gerrit/jenkins integration is perhaps
>     worthy of a discussion?
>
>
> I believe it is worth a discussion. Since today is a holiday in the US
> and many developers are offline I propose we pause this discussion for
> the rest of the day. I'll talk to Jay, Monty and Jim tomorrow and will
> come back with a plan to address the concerns raised on the list. Would
> that work for you?
>
> /stef
> 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.