Re: [PATCH 1/2] Provide a common malloc wrappers and palloc et al. emulation for frontend'ish environs

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH 1/2] Provide a common malloc wrappers and palloc et al. emulation for frontend'ish environs
Date: 2013-01-09 16:27:46
Message-ID: 25646.1357748866@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> On Wed, Jan 9, 2013 at 1:47 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>> On 2013-01-09 13:34:12 +0100, Magnus Hagander wrote:
>>> Am I the only one who finds this way of posting patches really annoying?

>> Well, I unsurprisingly don't ;)

> Yeah, that's not surprising :)

I'm with Magnus. This is seriously annoying, especially when the
"discussion" thread has a title not closely related to the "patch"
emails. (It doesn't help any that the list server doesn't manage to
deliver the emails in order, at least not to me --- more often than
not, they're spread out over a few minutes and interleaved with other
messages.)

I also don't find the argument that the commit messages are a substitute
for patch descriptions to be worth anything. Commit messages are, or
should be, for a different audience: they are for whoever writes the
release notes, or for historical purposes when someone is looking for
"which patches touched a particular area?". That's not the same as
explaining/justifying the patch for review purposes. Reviewers want
a lot more depth than is appropriate in a commit message. (TBH, I rarely
use any submitter's proposed commit message anyway, but that's just me.)

I'd prefer posting a single message with the discussion and the
patch(es). If you think it's helpful to split a patch into separate
parts for reviewing, add multiple attachments. But my experience is
that such separation isn't nearly as useful as you seem to think.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-01-09 16:37:46 Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)
Previous Message Tom Lane 2013-01-09 16:00:01 Re: PL/perl should fail on configure, not make