Re: [OpenStack-Infra] Zuul API
Hi Miguel, I'm not sure what the long term plans are for creating an API but I think it'd be safe to say if you're willing to work on it any improvements would be welcome! Currently zuul has an RPC framework that could be extended to expose additional functionality. At the moment it only implements a few methods. What kind of functions were you looking to expose over an API? Cheers, Josh From: Zuniga Vazquez, Miguel [mzigavzq...@paypal.com] Sent: Wednesday, March 19, 2014 3:44 AM To: openstack-infra@lists.openstack.org Subject: [OpenStack-Infra] Zuul API Hi everyone I got a few questions, I’ve been through your documentation on how to contribute but before I do all the setup I want to know from the list whether if the things that I’m asking would be considered or if there if there are even on the roadmap. I’m creating a CICD architecture for our dev teams and I was wondering if you: * Have plans for creating an API for Zuul? * If not would you be interested if our team contributes the API for it? In our experience Zuul is a powerful but for our non-openstack use cases and to incorporate it to multiple systems/applications the lack of an API makes it difficult to implement. Thoughts? Miguel Zuniga Cloud Infrastructure Engineering eBay Inc. / PayPal ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] [infra] Meeting Tuesday March 18th at 19:00 UTC
On Mon, Mar 17, 2014 at 9:22 AM, Elizabeth Krumbach Joseph wrote: > The OpenStack Infrastructure (Infra) team is hosting our weekly > meeting tomorrow, Tuesday March 18th, at 19:00 UTC in > #openstack-meeting Meeting minutes and log here: Minutes: http://eavesdrop.openstack.org/meetings/infra/2014/infra.2014-03-18-19.02.html Minutes (text): http://eavesdrop.openstack.org/meetings/infra/2014/infra.2014-03-18-19.02.txt Log: http://eavesdrop.openstack.org/meetings/infra/2014/infra.2014-03-18-19.02.log.html -- Elizabeth Krumbach Joseph || Lyz || pleia2 http://www.princessleia.com ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Announcing a new infrastructure project, Vinz code review system.
On Tue, Mar 18, 2014 at 12:49 PM, Monty Taylor wrote: > Also, I don't think we're going to suggest moving to it until it's good. > Or better. It will need to be better. As for myself, I would think that the better part would come from fact that it would be coded in python. There is so many times I had the thought, "That would be nice if gerrit could do that minor thing, that should be trivial to add" but thinking that i need to start to get that rusty eclipse and start dealing with maven deps and bunch of other stuff I don't (and want to) remember about that I have gave up. Chmouel. ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Announcing a new infrastructure project, Vinz code review system.
On 3/18/14, 8:18 AM, "Sean Dague" wrote: > >As long as this is going to be evaluated strongly at the end of the >process (including for the power user), I'm fine with that, and will >drop it at this point. > > -Sean Our intent is to not put out something that will not fit the needs of the team as a whole. It is true that I have not been that involved in commit reviewing, but one of the developers working on this project with me is in the higher up in the review count. He is currently sitting at 660+ reviews in the Icehouse cycle so he has a lot of experience with Gerrit. I like the idea of taking a step back and starting with the basis of a well defined UI around Gerrit as a first step, but I think this should be a small portion of the process as working towards a backend that can help our pipeline will be a great thing. What I am thinking might be the best approach is a two pronged attack to start: 1. Start on an AngularJS wrapper to Gerrit that is purely based around a REST API. 2. Begin with a common core that can slowly be extended to provide replacement to the Gerrit REST api along with filling in where we have issues with our current pipeline. -Ph ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Announcing a new infrastructure project, Vinz code review system.
On 03/18/2014 07:49 AM, Monty Taylor wrote: > On 03/18/2014 06:55 AM, Sean Dague wrote: >> On 03/18/2014 06:04 AM, Thierry Carrez wrote: >>> Monty Taylor wrote: Which means, although I tend to have a side which agrees with Clint and Clark that replacing gerrit is a bit of a potential giant rathole - I also think that making a scalable thing that architecturally fits with the other things we've got would be nice. >>> >>> It would be nice. But I think there are two major differences between >>> StoryBoard and Vinz from a development effort perspective... >>> >>> First, task tracking is fundamentally simple. As my POC proved, it's >>> just a few database tables -- the complexity you add on top of it is >>> just pure bonus. I see the basic code review functionality and the >>> manipulation of associated git repositories as a much more complex >>> endeavor. >>> >>> Second, I think Launchpad created a lot of developer itches that >>> StoryBoard hopefully will allow them to scratch. So we can hope to see >>> our developers help with StoryBoard in the future... I'm not sure Gerrit >>> created enough pain so far. Yes it's ugly but it gets the work done >>> pretty well. Could you point to a specific shortcoming that you can't >>> address in the legacy app and that would be the killer feature ? In >>> StoryBoard, that would be the ability to track cross-project features >>> with tons of tasks. >>> >>> Don't get me wrong, I don't want to prevent anyone from working on >>> anything they would like to. I'm just afraid that this is a large >>> project and I don't see it attracting enough contributors to be a >>> long-term sustainable alternative... potentially making it a gigantic >>> distraction. >> >> I agree that if it's a problem that a set of people really want to >> solve, so be it. >> >> Personally though, as one of the people that's probably spend as much >> time in Gerrit as anyone - >> http://stackalytics.com/?release=icehouse&metric=marks&project_type=openstack&module=&company=&user_id= >> >> I think the bar for replacement is really high. Because if a new tool >> impacts my ability to review code in any negative way, be it accuracy or >> volume, then I'm going to be properly annoyed. >> >> Which I do think is a difference between StoryBoard and this. With >> launchpad the power users stopped being able to do their job at all, to >> the point where many projects largely opt out of blueprints / bugs. >> That's not true for code review. It's actually kind of the opposite, as >> we have started moving non code things into Gerrit because it's actually >> very good at it's of recording votes, seeing specific comments, and >> recording history. >> >> So this has to not only be better for deployers, but it has to be better >> for us as core reviewers. Review bandwidth is our number one constrained >> resource in OpenStack, and has been for years, so any negative impact >> there would be as damaging to a release as us disabling the gate >> entirely. >> >> So who on the Vinz design team has regularly done 2000 gerrit reviews a >> year to ensure that level of through put isn't impacted (in any gerrit, >> doesn't have to be the community one)? Because that's my primary >> concern. A new project to replace a key system I rely on every day. >> Whose quirks I've come to understand well. With a set of tools that I >> have to further optimize it. And a team that I've never heard of before, >> that I see no track record of using the community gerrit in any volume, >> coming forward to propose a replacement. So please understand I have >> very deep concerns. > > I think this is a bit harsh on the folks suggesting that they work on this. > > Before I expand on that - I'd like to point out that gerrit is TERRIBLE > at dealing with the volume of reviews we all have. I believe the nova > core team recently was discussing putting attempts at new UI shims on > top of gerrit to try to deal with queuing and prioritization better. I, > for one, cannot deal with the mass of stuff I'm supposed to be reviewing > worth a crap. I'd love a better UI. > > Back to the vinz proposal. > > The team who is proposing it has no track record in infra. However, they > did start exactly right - the contacted both Jim and I (and apparently > fungi) and we talked with them about design ideas and they're moving in > that direction. > > Turns out - Jim and I already had design ideas, because we'd just had a > conversation about what a replacement design would look like - mainly > because of the monolithic gerrit design and the fact that we can forsee > surpassing its ability to deal with our traffic. I'm pretty sure that he > and I count as having done tons of reviews. > > I'm not worried about whether it's successful or not - precisely because > the team hasn't interacted with us, which means if it's a COMPLETE > failure, it's not a loss of resources on the current team. > > Also, I don't think we're going to suggest moving to it
Re: [OpenStack-Infra] Announcing a new infrastructure project, Vinz code review system.
On 03/18/2014 07:49 AM, Monty Taylor wrote: On 03/18/2014 06:55 AM, Sean Dague wrote: On 03/18/2014 06:04 AM, Thierry Carrez wrote: Monty Taylor wrote: Which means, although I tend to have a side which agrees with Clint and Clark that replacing gerrit is a bit of a potential giant rathole - I also think that making a scalable thing that architecturally fits with the other things we've got would be nice. It would be nice. But I think there are two major differences between StoryBoard and Vinz from a development effort perspective... First, task tracking is fundamentally simple. As my POC proved, it's just a few database tables -- the complexity you add on top of it is just pure bonus. I see the basic code review functionality and the manipulation of associated git repositories as a much more complex endeavor. Second, I think Launchpad created a lot of developer itches that StoryBoard hopefully will allow them to scratch. So we can hope to see our developers help with StoryBoard in the future... I'm not sure Gerrit created enough pain so far. Yes it's ugly but it gets the work done pretty well. Could you point to a specific shortcoming that you can't address in the legacy app and that would be the killer feature ? In StoryBoard, that would be the ability to track cross-project features with tons of tasks. Don't get me wrong, I don't want to prevent anyone from working on anything they would like to. I'm just afraid that this is a large project and I don't see it attracting enough contributors to be a long-term sustainable alternative... potentially making it a gigantic distraction. I agree that if it's a problem that a set of people really want to solve, so be it. Personally though, as one of the people that's probably spend as much time in Gerrit as anyone - http://stackalytics.com/?release=icehouse&metric=marks&project_type=openstack&module=&company=&user_id= I think the bar for replacement is really high. Because if a new tool impacts my ability to review code in any negative way, be it accuracy or volume, then I'm going to be properly annoyed. Which I do think is a difference between StoryBoard and this. With launchpad the power users stopped being able to do their job at all, to the point where many projects largely opt out of blueprints / bugs. That's not true for code review. It's actually kind of the opposite, as we have started moving non code things into Gerrit because it's actually very good at it's of recording votes, seeing specific comments, and recording history. So this has to not only be better for deployers, but it has to be better for us as core reviewers. Review bandwidth is our number one constrained resource in OpenStack, and has been for years, so any negative impact there would be as damaging to a release as us disabling the gate entirely. So who on the Vinz design team has regularly done 2000 gerrit reviews a year to ensure that level of through put isn't impacted (in any gerrit, doesn't have to be the community one)? Because that's my primary concern. A new project to replace a key system I rely on every day. Whose quirks I've come to understand well. With a set of tools that I have to further optimize it. And a team that I've never heard of before, that I see no track record of using the community gerrit in any volume, coming forward to propose a replacement. So please understand I have very deep concerns. I think this is a bit harsh on the folks suggesting that they work on this. Before I expand on that - I'd like to point out that gerrit is TERRIBLE at dealing with the volume of reviews we all have. I believe the nova core team recently was discussing putting attempts at new UI shims on top of gerrit to try to deal with queuing and prioritization better. I, for one, cannot deal with the mass of stuff I'm supposed to be reviewing worth a crap. I'd love a better UI. Back to the vinz proposal. The team who is proposing it has no track record in infra. However, they did start exactly right - the contacted both Jim and I (and apparently fungi) and we talked with them about design ideas and they're moving in that direction. Turns out - Jim and I already had design ideas, because we'd just had a conversation about what a replacement design would look like - mainly because of the monolithic gerrit design and the fact that we can forsee surpassing its ability to deal with our traffic. I'm pretty sure that he and I count as having done tons of reviews. I'm not worried about whether it's successful or not - precisely because the team hasn't interacted with us, which means if it's a COMPLETE failure, it's not a loss of resources on the current team. Also, I don't think we're going to suggest moving to it until it's good. Or better. It will need to be better. So I for one welcome the effort. Either it will work and we can use it and it will make our lives better - or it won't and we won't touch it. Storyboard was started by the person who was the #1 user of Launchp
Re: [OpenStack-Infra] Announcing a new infrastructure project, Vinz code review system.
On 03/18/2014 06:55 AM, Sean Dague wrote: On 03/18/2014 06:04 AM, Thierry Carrez wrote: Monty Taylor wrote: Which means, although I tend to have a side which agrees with Clint and Clark that replacing gerrit is a bit of a potential giant rathole - I also think that making a scalable thing that architecturally fits with the other things we've got would be nice. It would be nice. But I think there are two major differences between StoryBoard and Vinz from a development effort perspective... First, task tracking is fundamentally simple. As my POC proved, it's just a few database tables -- the complexity you add on top of it is just pure bonus. I see the basic code review functionality and the manipulation of associated git repositories as a much more complex endeavor. Second, I think Launchpad created a lot of developer itches that StoryBoard hopefully will allow them to scratch. So we can hope to see our developers help with StoryBoard in the future... I'm not sure Gerrit created enough pain so far. Yes it's ugly but it gets the work done pretty well. Could you point to a specific shortcoming that you can't address in the legacy app and that would be the killer feature ? In StoryBoard, that would be the ability to track cross-project features with tons of tasks. Don't get me wrong, I don't want to prevent anyone from working on anything they would like to. I'm just afraid that this is a large project and I don't see it attracting enough contributors to be a long-term sustainable alternative... potentially making it a gigantic distraction. I agree that if it's a problem that a set of people really want to solve, so be it. Personally though, as one of the people that's probably spend as much time in Gerrit as anyone - http://stackalytics.com/?release=icehouse&metric=marks&project_type=openstack&module=&company=&user_id= I think the bar for replacement is really high. Because if a new tool impacts my ability to review code in any negative way, be it accuracy or volume, then I'm going to be properly annoyed. Which I do think is a difference between StoryBoard and this. With launchpad the power users stopped being able to do their job at all, to the point where many projects largely opt out of blueprints / bugs. That's not true for code review. It's actually kind of the opposite, as we have started moving non code things into Gerrit because it's actually very good at it's of recording votes, seeing specific comments, and recording history. So this has to not only be better for deployers, but it has to be better for us as core reviewers. Review bandwidth is our number one constrained resource in OpenStack, and has been for years, so any negative impact there would be as damaging to a release as us disabling the gate entirely. So who on the Vinz design team has regularly done 2000 gerrit reviews a year to ensure that level of through put isn't impacted (in any gerrit, doesn't have to be the community one)? Because that's my primary concern. A new project to replace a key system I rely on every day. Whose quirks I've come to understand well. With a set of tools that I have to further optimize it. And a team that I've never heard of before, that I see no track record of using the community gerrit in any volume, coming forward to propose a replacement. So please understand I have very deep concerns. I think this is a bit harsh on the folks suggesting that they work on this. Before I expand on that - I'd like to point out that gerrit is TERRIBLE at dealing with the volume of reviews we all have. I believe the nova core team recently was discussing putting attempts at new UI shims on top of gerrit to try to deal with queuing and prioritization better. I, for one, cannot deal with the mass of stuff I'm supposed to be reviewing worth a crap. I'd love a better UI. Back to the vinz proposal. The team who is proposing it has no track record in infra. However, they did start exactly right - the contacted both Jim and I (and apparently fungi) and we talked with them about design ideas and they're moving in that direction. Turns out - Jim and I already had design ideas, because we'd just had a conversation about what a replacement design would look like - mainly because of the monolithic gerrit design and the fact that we can forsee surpassing its ability to deal with our traffic. I'm pretty sure that he and I count as having done tons of reviews. I'm not worried about whether it's successful or not - precisely because the team hasn't interacted with us, which means if it's a COMPLETE failure, it's not a loss of resources on the current team. Also, I don't think we're going to suggest moving to it until it's good. Or better. It will need to be better. So I for one welcome the effort. Either it will work and we can use it and it will make our lives better - or it won't and we won't touch it. Storyboard was started by the person who was the #1 user of Launchpad in our Community, bec
Re: [OpenStack-Infra] Meetbot for #magnetodb channel
On 03/18/2014 07:28 AM, Ilya Sviridov wrote: Hello Infra team, During work on MagnetoDB on a daily basis, we have faced with necessity of OpenStack meetbot for our project channel. Having a daily scrum meetings, we would love to use it for tracking action items and make it available for everyone available. Is it possble to add meetbot to #magnetodb IRC channed at FreeeNode? Yup! You can make a patch - openstack-infra/config:modules/openstack_project/manifests/eavesdrop.pp Monty ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
[OpenStack-Infra] Meetbot for #magnetodb channel
Hello Infra team, During work on MagnetoDB on a daily basis, we have faced with necessity of OpenStack meetbot for our project channel. Having a daily scrum meetings, we would love to use it for tracking action items and make it available for everyone available. Is it possble to add meetbot to #magnetodb IRC channed at FreeeNode? Feel free to contact me in IRC or E-mail. Thanks Ilya Sviridov isviridov @ FreeNode ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Announcing a new infrastructure project, Vinz code review system.
Le 17/03/2014 20:43, Clint Byrum a écrit : > http://www.ohloh.net/p/mediawiki - 233 developers Hello, I am one of the Wikimedia dev and part of the group maintaining Gerrit. We have roughly 400 Gerrit users. We had a couple persons involved in enhancing Gerrit (for example a plugin to interact with Bugzilla). Nowadays, we barely have anyone coding for it beside fixing bugs that strike us. We do upgrade it from upstream as fast as possible though. Our two majors concerns are the web interface usability and the lack of easy branching + merge --no-ff Some folks are pushing to migrate to phabricator which is more or less integrate issue tracking, code quality and the review process. cheers, -- Antoine "hashar" Musso ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Announcing a new infrastructure project, Vinz code review system.
On 03/18/2014 06:04 AM, Thierry Carrez wrote: > Monty Taylor wrote: >> Which means, although I tend to have a side which agrees with Clint and >> Clark that replacing gerrit is a bit of a potential giant rathole - I >> also think that making a scalable thing that architecturally fits with >> the other things we've got would be nice. > > It would be nice. But I think there are two major differences between > StoryBoard and Vinz from a development effort perspective... > > First, task tracking is fundamentally simple. As my POC proved, it's > just a few database tables -- the complexity you add on top of it is > just pure bonus. I see the basic code review functionality and the > manipulation of associated git repositories as a much more complex endeavor. > > Second, I think Launchpad created a lot of developer itches that > StoryBoard hopefully will allow them to scratch. So we can hope to see > our developers help with StoryBoard in the future... I'm not sure Gerrit > created enough pain so far. Yes it's ugly but it gets the work done > pretty well. Could you point to a specific shortcoming that you can't > address in the legacy app and that would be the killer feature ? In > StoryBoard, that would be the ability to track cross-project features > with tons of tasks. > > Don't get me wrong, I don't want to prevent anyone from working on > anything they would like to. I'm just afraid that this is a large > project and I don't see it attracting enough contributors to be a > long-term sustainable alternative... potentially making it a gigantic > distraction. I agree that if it's a problem that a set of people really want to solve, so be it. Personally though, as one of the people that's probably spend as much time in Gerrit as anyone - http://stackalytics.com/?release=icehouse&metric=marks&project_type=openstack&module=&company=&user_id= I think the bar for replacement is really high. Because if a new tool impacts my ability to review code in any negative way, be it accuracy or volume, then I'm going to be properly annoyed. Which I do think is a difference between StoryBoard and this. With launchpad the power users stopped being able to do their job at all, to the point where many projects largely opt out of blueprints / bugs. That's not true for code review. It's actually kind of the opposite, as we have started moving non code things into Gerrit because it's actually very good at it's of recording votes, seeing specific comments, and recording history. So this has to not only be better for deployers, but it has to be better for us as core reviewers. Review bandwidth is our number one constrained resource in OpenStack, and has been for years, so any negative impact there would be as damaging to a release as us disabling the gate entirely. So who on the Vinz design team has regularly done 2000 gerrit reviews a year to ensure that level of through put isn't impacted (in any gerrit, doesn't have to be the community one)? Because that's my primary concern. A new project to replace a key system I rely on every day. Whose quirks I've come to understand well. With a set of tools that I have to further optimize it. And a team that I've never heard of before, that I see no track record of using the community gerrit in any volume, coming forward to propose a replacement. So please understand I have very deep concerns. Storyboard was started by the person who was the #1 user of Launchpad in our Community, because launchpad was a giant efficiency problem in making good OpenStack releases. So this is not the same thing as Storyboard. There are other options besides whole sale replacement. For instance, with a modern Gerrit the UI could be replaced with a custom one built on top of the REST api. That seems like a better starting point, as you could sort out the UX challenges first, get an alt interfaces that we all agree on, get tons of feedback in a live / high volume environment. It can be a 2nd interface that gets used along side the existing one for a long time, and constantly iterated on to demonstrate improvements. Then the backend switch could be taken on after the UX has proven itself. This would have the advantage of being able to be dogfooded really soon (as soon as the gerrit 2.8 deploy completes). It also means that for UI that wasn't completed yet, it could fall back to gerrit interfaces. Anyway, realize that unlike launchpad, gerrit actually has fans. And while I 100% agree Google doesn't know how to run an open source project (which I think is the a challenge for any organization that largely collocates their teams, as anyone not within walking distance is *other*), what they've managed to produce is still pretty reasonable for those of us using it every day. -Sean -- Sean Dague Samsung Research America s...@dague.net / sean.da...@samsung.com http://dague.net signature.asc Description: OpenPGP digital signature ___ OpenStack-Infra mailin
Re: [OpenStack-Infra] Announcing a new infrastructure project, Vinz code review system.
Monty Taylor wrote: > Which means, although I tend to have a side which agrees with Clint and > Clark that replacing gerrit is a bit of a potential giant rathole - I > also think that making a scalable thing that architecturally fits with > the other things we've got would be nice. It would be nice. But I think there are two major differences between StoryBoard and Vinz from a development effort perspective... First, task tracking is fundamentally simple. As my POC proved, it's just a few database tables -- the complexity you add on top of it is just pure bonus. I see the basic code review functionality and the manipulation of associated git repositories as a much more complex endeavor. Second, I think Launchpad created a lot of developer itches that StoryBoard hopefully will allow them to scratch. So we can hope to see our developers help with StoryBoard in the future... I'm not sure Gerrit created enough pain so far. Yes it's ugly but it gets the work done pretty well. Could you point to a specific shortcoming that you can't address in the legacy app and that would be the killer feature ? In StoryBoard, that would be the ability to track cross-project features with tons of tasks. Don't get me wrong, I don't want to prevent anyone from working on anything they would like to. I'm just afraid that this is a large project and I don't see it attracting enough contributors to be a long-term sustainable alternative... potentially making it a gigantic distraction. -- Thierry Carrez (ttx) ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Announcing a new infrastructure project, Vinz code review system.
On 03/17/2014 08:07 PM, Philip Schwartz wrote: On 3/17/14, 5:33 PM, "Sean Dague" wrote: Have you considered other open source efforts to build upon, like phabricator? That came up on IRC a few nights ago by Ryan Lane. And it seems like a lot of mileage could be gained from contributing to an existing upstream, even if it's an alternative one to gerrit. I have nothing against starting from a known base if there is something that meets a majority of our needs and can be easily enhanced. With that said, I would not feel that Phabricator would fit into that. It is not bad at what it does, but happens to be a very odd PHP app. From my experience with PHP (which is vast), server side applications that do any functionality that is beyond being just a web app tend to have poor code bases and very strange hacks to get around the fastcgi or mod_php sandbox that PHP runs in. I looked at Phabricator before storyboard - I agree with Philip. It's a good application, but I don't think it's a good application for us. Same as with bug tracking - we have some really specific requirements. I have been looking at a lot of things that all are code review related and also looked at review board as suggested earlier. All have elements that I like and do not like and none of them meet the needs of the OpenStack project completely. Personally I feel that making an attempt at meeting our needs while leveraging external libraries is good idea, and using things that applications like review board use and some of the libraries they use is a good starting point. I think we have an opinionated view of how this works - and as it interfaces with things like zuul and turbo-hipster, we deal with a massive amount of things that are pretty specific to us. I'm not saying that's a thing to be proud of or a thing to be ashamed of - it simply is. Which means, although I tend to have a side which agrees with Clint and Clark that replacing gerrit is a bit of a potential giant rathole - I also think that making a scalable thing that architecturally fits with the other things we've got would be nice. I don't really care about the java v. python part - but ultimately gerrit is designed as a single monolithic service - and although we haven't hit its ability to scale .. yet ... I think it's only a matter of time. The google guys run their gerrit on a google specific sekrit backend after all. ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
