Re: Considering Gerrit for CFs

On Wed, Feb 6, 2013 at 10:07 PM, Josh Berkus <josh(at)agliodbs(dot)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 Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/