From: | Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Bruce Momjian <bruce(at)momjian(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: Releasing in September |
Date: | 2016-01-20 20:04:50 |
Message-ID: | 569FE862.3000201@archidevsys.co.nz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 21/01/16 06:40, Tom Lane wrote:
> Magnus Hagander <magnus(at)hagander(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-01-20 20:06:01 | Re: Odd behavior in foreign table modification (Was: Re: Optimization for updating foreign tables in Postgres FDW) |
Previous Message | Simon Riggs | 2016-01-20 19:49:34 | Re: Releasing in September |