Re: Patch Submission Guidelines

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Patch Submission Guidelines
Date: 2006-02-14 21:00:50
Message-ID: 20060214210050.GF2435@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Note: People following this should probably read this post on -patches
in the archive:
http://archives.postgresql.org/pgsql-patches/2006-02/msg00207.php

On Tue, Feb 14, 2006 at 05:20:55PM +0000, Simon Riggs wrote:
> Many patch submitters discover that they fall foul of various "you
> should have done"s at a late stage of the patch review process.

> I would like to suggest that we increase substantially the FAQ entries
> relating to patch submission. By we, I actually mean please could the
> committers sit down and agree some clarified written guidelines?

As I remember, there is a disinclination to increase the size of the
FAQ very much. This suggests maintaining it as a seperate document. Or
alternatively attach it as an appendix to the main documentation.

I liked your list BTW. It covers most of the common issues. I think you
missed SQL standards related issues. If you're submitting a patch to
increase SQL conformence, you need to say so.

> I believe if we do this we will have more patches produced, reviewed and
> committed from our available resources, as well as more hackers more
> regularly willing to face the challenges of getting a quality patch
> accepted. In the end we will live and die by the number of people
> submitting and how many of those go on to become regular contributors
> (should I say "serial hackers"?)

One real big issue is feedback. Some patches are obviously going to
receive much more feedback than others. But in some places there are
really very few people that can give meaningful feedback. I honestly
don't know what we can do about that other than try to grow the number
of people :(

Related to that is testing. I get the impression that very few patches
are tested by people other than the author before submission. This is
one thing the linux kernel does well. There exist trees that will take
almost any patch and people who download that and hammer it. Great for
testing stability before accepting it into the real tree.

Finally, several of the patches committed the last few days have been
fixing minor bugs or platform specific issues with various patches. One
thing that would be really nice is a real patch queue and have the
buildfarm machines occasionally apply one of the patches and try to run
with it. For people that don't have access to all sorts of
architechtures, it would be a great way of getting feedback on the
portability of the patch prior to actual submission to -HEAD.

Does give you ideas, doesn't it?

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2006-02-14 21:17:57 Re: Patch Submission Guidelines
Previous Message James William Pye 2006-02-14 19:35:21 Re: Copy From & Insert UNLESS

Browse pgsql-patches by date

  From Date Subject
Next Message Andrew Klosterman 2006-02-14 21:02:17 Re: BUG #2246: Bad malloc interactions: ecpg, openssl
Previous Message Tom Lane 2006-02-14 20:51:43 Re: BUG #2246: Bad malloc interactions: ecpg, openssl