[hackers-jp: 216] [Fwd: Re: [HACKERS] Patch Submission Guidelines]

[Satoshi Nagayasu]

もう一本。
＃スレッド追いながら転送しているのがバレバレですな。笑

パッチをレビューするのがインターナルに精通する早道ですよ、と。
彼の場合は経験からそう言っているのかもしれませんね。

-------- Original Message --------
Subject: Re: [HACKERS] Patch Submission Guidelines
Date: Tue, 14 Feb 2006 21:47:05 -0500
From: Neil Conway <neilc ＠ samurai.com>
To: Simon Riggs <simon ＠ 2ndquadrant.com>
CC: Tom Lane <tgl ＠ sss.pgh.pa.us>, Andrew Dunstan <andrew ＠ dunslane.net>,        Martijn van Oosterhout <kleptog ＠ svana.org>,        pgsql-hackers ＠ postgresql.org
References: <1139937655.1258.1004.camel ＠ localhost.localdomain>	 <20060214210050.GF2435 ＠ svana.org> <43F24905.9010401 ＠ dunslane.net>	 <1139954052.1258.1021.camel ＠ localhost.localdomain>	 <23467.1139956134 ＠ sss.pgh.pa.us>	 <1139957653.1258.1040.camel ＠ localhost.localdomain>

On Tue, 2006-02-14 at 22:54 +0000, Simon Riggs wrote:
> On Tue, 2006-02-14 at 17:28 -0500, Tom Lane wrote:
> > IMHO the thing we are really seriously short of is patch reviewers.
[...]
> Well that was the basis of my original suggestion. Publish some
> guidelines and everybody becomes a patch reviewer.

I agree guidelines would be help, but I hope (and doubt!) that is not
what is stopping people from reviewing patches. Anyone with the time and
inclination can review patches, guidelines or not -- reviewing patches
is actually a good way to learn more about Postgres internals. The
method I personally use for reviewing patches is trivial:

    for each hunk in the patch
        what is the intent of the hunk?
        is there a better way to accomplish that?

(Actually applying the patch to a local tree and then browsing the tree
can be helpful to understand the context each hunk is modifying.)

Of course, the first few patches you review, you'll probably spend more
time on step 1 than on step 2, and you might not produce very many
useful review comments. But that's what practice is for :)

Newbie patch reviewers might also try reviewing patches for client
applications (e.g. psql, pg_dump) that do not require as much knowledge
of the rest of the source tree. If you are competent at C, you can
probably hack on psql/pg_dump/etc. with little additional knowledge.
Similarly, reviewing documentation patches is another easy way to get
involved -- SGML style fixes, spelling/grammar improvements and the like
require no knowledge of PG at all.

-Neil



---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faq


-- 
NAGAYASU Satoshi <nagayasus ＠ nttdata.co.jp>