Open Stack

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, 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.

L