Re: Considering Gerrit for CFs - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Considering Gerrit for CFs
Date
Msg-id CABUevEyEyYZ58717QeVutJ0bgiN1fKDb0EEObVNax0+cZQRdJA@mail.gmail.com
Whole thread Raw
In response to Considering Gerrit for CFs  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Considering Gerrit for CFs
Re: Considering Gerrit for CFs
Re: Considering Gerrit for CFs
List pgsql-hackers
On Wed, Feb 6, 2013 at 10:07 PM, Josh Berkus <josh@agliodbs.com> wrote:
> Hackers,
>
> As an occasional CommitFest manager, I'm keenly aware of the makeshift
> nature of the CommitFest app.  If we want to go on using it -- and if we
> want to attract additional reviewers -- we need to improve it
> substantially.  What Robert built for us was supposed to be a second
> draft, not a final version.

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?


> The problem with doing it in-house is that the folks who can work on it
> and maintain it will be taking time away from developing PostgreSQL.  So
> I've been keeping an eye on third-party OSS apps for contribution
> management, waiting for one of them to mature enough that we can
> seriously consider using it.
>
> I think one of them has, now: Gerrit.  http://code.google.com/p/gerrit/
>
> I spent some time with OpenStack's main Gerrit admin while at LCA, and
> was fairly encouraged that Gerrit would be a big step up compared to our
> current ad-hoc PHP.  However, gerrit is designed to be git-centric

We have no ad-hoc PHP, but I'm assume you're referring to the cf
management app that's in 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.

Now, if we *want' to change our workflow, that's a different story, of
course. But a tool shouldn't dictate that.


> other git tools, though, it expects patches and not branches, so that
> would integrate well with what we do now.  It would also require
> supporting Java in our infrastructure.

We already have a certain amount of support for java in the
infrastructure. It does mandate that it doesn't have any special
requirements on the java environment, of course - but as long as it
works with the one that ships on Debian, we can do it.


> 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?


> 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"?


> Thoughts?

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.

FWIW, what we have now could easily run on a box with 128Mb RAM...


--Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/



pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Considering Gerrit for CFs
Next
From: Josh Berkus
Date:
Subject: Re: Considering Gerrit for CFs