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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
