Re: Patch Submission Guidelines
От | Neil Conway |
---|---|
Тема | Re: Patch Submission Guidelines |
Дата | |
Msg-id | 1139971625.31672.37.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: Patch Submission Guidelines (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: Patch Submission Guidelines
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: