Open Stack

FWIW, we've received excellent support from the CI team on Gerrit and it
is working well for Keystone. The workflow has been simplified with the
rfc.sh script and the system has been available and performing reliably.

The ability to pull down, modify, and resubmit reviews works well and is
simple enough once you've done it once or twice.

Z

On 9/7/11 5:31 AM, "Monty Taylor" <mordred at inaugust.com> wrote:

>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 at lists.launchpad.net
>> [openstack-bounces+sandy.walsh=rackspace.com at lists.launchpad.net] on
>> behalf of Stefano Maffulli [smaffulli at gmail.com]
>> *Sent:* Monday, September 05, 2011 12:35 PM
>> *To:* openstack at lists.launchpad.net
>> *Subject:* Re: [Openstack] A possible alternative to Gerrit ...
>> 
>> 2011/9/5 Sandy Walsh <sandy.walsh at rackspace.com
>> <mailto:sandy.walsh at rackspace.com>>
>> 
>>     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 at lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>
>_______________________________________________
>Mailing list: https://launchpad.net/~openstack
>Post to     : openstack at 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.