Re: Considering Gerrit for CFs

> This is probably not something we should discuss right now - it's
> better discussed when we're not right inthe middle of a commitfest,
> no?

Well, *if* we were to change tooling, the time to do it would be during
beta.  Hence, bringing it up now.

> We have no ad-hoc PHP, but I'm assume you're referring to the cf
> management app that's in perl?

Sorry, "ad-hoc perl".

>> rather than email-centric, so it would modify our current email-centric
>> workflow (e.g. reviews are posted via a special git commit). Unlike
> 
> Previously, we've said we do not want to do this. And I think in
> general, it's a realliy bad idea to have a tool dictate the workflow.
> It should be the other way around.

Yeah.  It would be theoretically possible to change things so that
Gerrit would accept email reviews, but anyone who's worked with RT can
tell you that automated processing of email is error-prone.  That's why
nobody does it.  Note that Gerrit is perfectly capable of *sending*
email to the list, it's just *receiving* it which is an issue.

Mind you, when I explained our current CF review workflow for the SF
ReviewFest last year, the attendees thought I was insane. It's kept me
from doing more reviewfests. Our current workflow and tooling is
definitely a serious obstacle to gettng more reviewers.  Seems like a
good topic for the developer meeting.

>> The advantages in features would be substantial: a better interface,
>> ways to perform automated tasks (like remind submitters that a patch is
>> waiting on author), online diffs, automated testing integration, and a
>> configurable review workflow process.
> 
> Could you point to an example somewhere that we could check such features out?

This is a good place to start: https://review.openstack.org

>> The existing Gerrit community would be keen to have the PostgreSQL
>> project as a major user, though, and would theoretically help with
>> modification needs.  Current major users are OpenStack, Mediawiki,
>> LibreOffice and QT.
> 
> "theoretically"?

Well, I think we learned from Gforge that folks are more willing to
promise help than to deliver it.

> I just took a quick look at their system, and when they start talking
> about requirements in the 100's of Gb of RAM, 24 core machines and
> SSD, I get scared :) But that's to "scale" it - doesn't mention when
> you need to do anything like that. I'm assuming we'd be tiny.

Yeah, I have no idea.  Given that it's Java, I'd assume that
requirements would go up.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com