public inbox for [email protected]
help / color / mirror / Atom feedFrom: Magnus Hagander <[email protected]>
To: Daniel Farina <[email protected]>
Cc: Joshua D. Drake <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Josh Berkus <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: Considering Gerrit for CFs
Date: Thu, 7 Feb 2013 12:07:14 +0100
Message-ID: <CABUevEyU2eYCP1c-kFZtVckVm2w89RxBJwd37KoAeVpjg2b5bg@mail.gmail.com> (raw)
In-Reply-To: <CAAZKuFbXkGs_Dw-cNQ3LyU-d3JPVsKJ69mFkXBwk3HEtZcwyLQ@mail.gmail.com>
References: <[email protected]>
<CABUevEyEyYZ58717QeVutJ0bgiN1fKDb0EEObVNax0+cZQRdJA@mail.gmail.com>
<[email protected]>
<[email protected]>
<CAAZKuFbXkGs_Dw-cNQ3LyU-d3JPVsKJ69mFkXBwk3HEtZcwyLQ@mail.gmail.com>
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgsql-hackers>
On Thu, Feb 7, 2013 at 8:20 AM, Daniel Farina <[email protected]> wrote:
> On Wed, Feb 6, 2013 at 3:00 PM, Joshua D. Drake <[email protected]> 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 Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
view thread (35+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Considering Gerrit for CFs
In-Reply-To: <CABUevEyU2eYCP1c-kFZtVckVm2w89RxBJwd37KoAeVpjg2b5bg@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox