From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
Cc: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, "Andrew Dunstan" <andrew(at)dunslane(dot)net>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: How to submit a patch |
Date: | 2008-04-17 01:07:35 |
Message-ID: | 87ve2hp9uw.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-www |
"Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
> Workflow A:
>
> 1. You post patch to pgsql-patches
> 2. a committer picks it up immediately, and commits it.
I'm more interested in knowing what happens when a committer *doesn't* commit
it. Personally I would almost rather a committer not commit my patch but
instead return feedback on the first go-around than commit it.
I would rather hear about any objections and fix them myself and in the
process learn how to do it better next time. It just isn't as good a learning
experience when I read the commit diffs and have to try to figure out what the
rationale was for the changes.
That's why waiting until feature freeze was so awful from my point of view.
There was never any time left to return patches to the author so Tom ended up
reworking any patches we really wanted.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's PostGIS support!
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2008-04-17 01:37:40 | Re: How to submit a patch |
Previous Message | Stephen Denne | 2008-04-17 00:48:37 | Re: count(*) performance improvement ideas |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2008-04-17 01:37:40 | Re: How to submit a patch |
Previous Message | Greg Smith | 2008-04-16 23:02:06 | Re: How to submit a patch |