From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: a few thoughts on the schedule |
Date: | 2015-05-13 16:13:44 |
Message-ID: | 20150513161344.GJ12950@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
> But many new ideas are just plain bad, and others are things that nobody
> but the author cares about. We need to remember that every new feature
> we add creates an ongoing maintenance burden, and might foreclose better
> ideas later. I'd like to see a higher threshold for accepting feature
> patches than we seem to have applied of late.
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?
I guess we'd have to somebody making a summary of each patch, and their
own opinion. Then that list can be discussed. I don't really like that,
because it involves a fair amount of work and has a good bit of
potential for personal preferences to creep in. But I don't have a
better idea.
If necessary I'll do that for the first CF.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2015-05-13 16:15:43 | Re: Triaging the remaining open commitfest items |
Previous Message | Tom Lane | 2015-05-13 16:09:16 | Re: Triaging the remaining open commitfest items |