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: