On 21/01/16 06:40, Tom Lane wrote:
Magnus Hagander <mag...@hagander.net> writes:
That's pretty much what I suggested :)
Except that we need to do it for the last one as well. With the only
exception that the last one might be a bit longer. But the fact is that the
recent of CFs *and* releases, we've taken the approach of closing the CF
when everything in it is done or explicitly reviewed-and-bumped, and tried
really really hard not to bump things because nobody had time to look at
them. That's what I'm suggesting we change, and actually just cut them.
Yes, one of the reasons for the CFs was to allow people a fair chance to
get reviewed.But given that there isn't actually a deadline in practice
doesn't help with that.
Yeah. It's certainly unfair if someone's patch doesn't get reviewed,
but there are only 24 hours in a day, and we have a limited pool of
reviewer and committer manpower. I think we just have to say that
sometimes life is unfair.
I think it might also be a good idea if we could somehow distinguish
"nobody had time for that yet" from "nobody is interested", with an eye
to flat-out rejecting patches that no one cares enough about to review.
Maybe we could reduce the workload by inventing some kind of up-front
filter whereby a patch isn't even a candidate to get reviewed unless, say,
at least two people besides the author say "this sounds like it's worth
pursuing".
One of the other things I do not like about the current CF process is that
it's created a default assumption that most submitted patches should get
accepted eventually. It is *very* hard to reject a patch altogether in
the CF process: you more or less have to show cause why it should not get
accepted. That default is backwards. Maybe this isn't the process' fault
exactly, but it sure seems like that's how we approach patches now.
regards, tom lane
Possibly the emphasis should be on what patches should be ACCEPTED,
rather than on what patches should be REJECTED?
Then there is less stigma in a patch missing out, and people don't have
justify rejecting patches.
Cheers,
Gavin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
