Re: Releasing in September

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

In response to

Browse pgsql-hackers by date

  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