Re: Considering Gerrit for CFs

On Wed, Feb 6, 2013 at 3:00 PM, Joshua D. Drake <jd(at)commandprompt(dot)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.

* 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.

--
fdr