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

On Thu, Feb 7, 2013 at 8:20 AM, Daniel Farina <daniel@heroku.com> wrote:
> On Wed, Feb 6, 2013 at 3:00 PM, Joshua D. Drake <jd@commandprompt.com> wrote:
>>
>> On 02/06/2013 01:53 PM, Tom Lane wrote:
>>
>>> ... if it's going to try to coerce us out of our email-centric habits,
>>> then I for one am very much against it.  To me, the problems with the
>>> existing CF app are precisely that it's not well enough integrated with
>>> the email discussions.  The way to fix that is not to abandon email (or
>>> at least, it's not a way I wish to pursue).
>>
>>
>> The email centric habits are by far the biggest limiting factor we have.
>> Email was never designed for integral collaboration. That said, I see no way
>> around it. I have brought up this idea before but, Redmine has by far served
>> the purposes (with a little effort) of CMD and it also integrates with GIT.
>> It also does not break the email work flow. It does not currently allow
>> commands via email but that could be easily (when I say easily, I mean it)
>> added.
>>
>> Just another thought.
>
> I don't think controlling things by email is the issue.  I have used
> the usual litany of bug trackers and appreciate the
> correspondence-driven model that -hackers and -bugs uses pretty
> pleasant.  If nothing else, the uniform, well-developed, addressable,
> and indexed nature of the archives definitely provides me a lot of
> value that I haven't really seen duplicated in other projects that use
> structured bug or patch tracking.  The individual communications tend
> to be of higher quality -- particularly to the purpose of later
> reference -- maybe a byproduct of the fact that prose is on the
> pedestal.
>
> There are obvious tooling gaps (aren't there always?), but I don't
> really see the model as broken, and I don't think I've been around
> pgsql-hackers exclusively or extensively enough to have developed
> Stockholm syndrome.
>
> I also happen to feel that the commitfest application works rather
> well for me in general.  Sure, I wish that it might slurp up all
> submitted patches automatically or something like that with default
> titles or something or identify new versions when they appear, but
> I've always felt that skimming the commitfest detail page for a patch
> was useful.  It was perhaps harder to know if the commitfest page I
> was looking at was complete or up to date or not, although it often
> is.
>
> Here's what I find most gut-wrenching in the whole submit-review-commit process:
>
> * When a reviewer shows up a couple of weeks later and says "this
> patch doesn't apply" or "make check crash" or "fails to compile".
> It's especially sad because the reviewer has presumably cut out a
> chunk of time -- now probably aborted -- to review the patch.
> Machines can know these things automatically.

If the report is *just* "this patch doesn't apply", I agree. If the
reviewer is more "this patch doesn't apply anymore. Here's an adjusted
version that does" it has a value in itself - because somebody else
just got more familiar with that part of the code.

> * When on occasion patches are submitted with non-C/sh/perl suites
> that may not really be something that anyone wants to be a
> build/source tree, but seem like they might do a better job testing
> the patch.  The inevitable conclusion is that the automated test
> harness is tossed, or never written because it is known it will have
> no place to live after a possible commit.  Somehow I wish those could
> live somewhere and run against all submitted patches.
>
> I've toyed a very, very tiny bit with running build farm clients on
> Heroku with both of these in mind, but haven't revisited it in a
> while.

It's certainly been loosely discusse dbefore as a possible enhancement
- but the main thing being it basically *has* to be run in a
virtualized environment that's thrown away, or you're going to open
all sorts of issues with running arbitrary code on peoples machines.
Of course, virtualization is kind of what you guys do :)


Personally, I find the most annoying thing with the current process
being when reviewers post their reviews as a completely separate
thread, instead of replying in the original thread. This causes
context switches when parsing things, because now you have to jump
back and forth between the CF app and your mail reader. But it's still
only on the annoyance side, I think the process in general is not
broken. (That said, I *have* been on the inside a long time, *and* I
live in Stockholm, so I might well have that syndrome)

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