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

From Tom Lane
Subject Re: [PATCH 1/2] Provide a common malloc wrappers and palloc et al. emulation for frontend'ish environs
Date
Msg-id 25646.1357748866@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH 1/2] Provide a common malloc wrappers and palloc et al. emulation for frontend'ish environs  (Magnus Hagander <magnus@hagander.net>)
Responses Re: [PATCH 1/2] Provide a common malloc wrappers and palloc et al. emulation for frontend'ish environs
Re: [PATCH 1/2] Provide a common malloc wrappers and palloc et al. emulation for frontend'ish environs
List pgsql-hackers
Magnus Hagander <magnus@hagander.net> writes:
> On Wed, Jan 9, 2013 at 1:47 PM, Andres Freund <andres@2ndquadrant.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



pgsql-hackers by date:

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