Re: Releasing in September - Mailing list pgsql-hackers

From Gavin Flower
Subject Re: Releasing in September
Date
Msg-id 569FE862.3000201@archidevsys.co.nz
Whole thread Raw
In response to Re: Releasing in September  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 21/01/16 06:40, Tom Lane wrote:
> Magnus Hagander <magnus@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




pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Releasing in September
Next
From: Robert Haas
Date:
Subject: Re: Odd behavior in foreign table modification (Was: Re: Optimization for updating foreign tables in Postgres FDW)