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 [mord...@inaugust.com] Sent: Tuesday, September 06, 2011 11:31 PM To: Sandy Walsh Cc: Stefano Maffulli; openstack@lists.launchpad.net 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....@lists.launchpad.net > [openstack-bounces+sandy.walsh=rackspace....@lists.launchpad.net] on > behalf of Stefano Maffulli [smaffu...@gmail.com] > *Sent:* Monday, September 05, 2011 12:35 PM > *To:* openstack@lists.launchpad.net > *Subject:* Re: [Openstack] A possible alternative to Gerrit ... > > 2011/9/5 Sandy Walsh <sandy.wa...@rackspace.com > <mailto:sandy.wa...@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@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