On 05/13/2015 09:27 AM, Tom Lane wrote:
Andres Freund <and...@anarazel.de> writes:
On 2015-05-13 11:52:40 -0400, Tom Lane wrote:
One thing that continues to bother me about the commitfest process is that
it's created a default expectation that things get committed eventually.
Agreed that this is a problem. I think we need to work on giving that
feedback rather sooner than later. It's one thing to be given a -1 a
week or two after a patch gets proposed, another being given it 10
revisions and half a year later.
How about we really try to triage the patches a) before the CF starts,
b) half into the CF?
We keep talking about doing something like that (I remember it's come up
several times in the annual developer meetings), and then not actually
doing it. But I agree it seems like a good idea.
What if:
* Commitfest starts at branch.
* Accept new patches for 9.6 until X date
* At X date, tree is closed and patch review begins
* Patch review continues until all patches are committed, kicked or Y
date is met.
* At Y date, we go to Alpha
* At Z date, we go to Beta
Well crap, I ran out of sequence letters but you get the idea. In short,
no more ethereal "We kind of do this on this date sort of". Stick to it,
it may suck sometimes but it is really the only reasonable way to do it
anymore.
JD
regards, tom lane
--
Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Announcing "I'm offended" is basically telling the world you can't
control your own emotions, so everyone else should do it for you.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
