Re: Releasing in September

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