On Fri, Jan 22, 2016 at 6:21 PM, Andres Freund <and...@anarazel.de> wrote: > On 2016-01-22 08:50:15 -0600, Jim Nasby wrote: >> I think that's a great way to ensure we shrink the pool of reviewers when >> someone works on a patch and then it goes nowhere. > > True, it really sucks. But what's your counter proposal? Commitfests > dragging on forever, and people burning out on continually feeling they > need to work on them? Hasn't worked out well.
Well my point of view is that the entire reason for commitfests is to ensure every patch gets at least some feedback. If we're going to bounce patches without any feedback and only work on the patches that catchh people's interest then that's back where we were before commitfests. We used to see a lot of patches sit basically ignored until release time when Tom or someone would pick them up and rewrite them from scratch because that would be faster than trying to explain what's wrong and waiting for the original author to rewrite it. It really sucks for the original author to be ignored for a year and I think it's how we lost a lot of potential contributors. I think it's true that there are basically two successful lanes patches can be in. a) They're of wide interest and need concerted ongoing effort by multiple people to proceed and b) they're of narrow interest but really just need a thumbs up or pointer to what direction to head and the original author can proceed. The first clogs up the commitfest and dominates people's time when it probably belongs more in the normal development process. The latter is really what they were designed for. Perhaps it would make sense to alternate between "commitfests" that are intended to return feedback to authors so they can work on their patch and "developfests" where larger patches that need more discussion get covered. The latter are expected to drag on but shouldn't block other work whereas the commitfests are expected to get relatively short reviews and be bounced as "returned with feedback" quickly. Or perhaps we should just have two different "returned with feedback", one of which is "under discussion" which means the patch has seen some discussion and therefore doesn't need to be in the commitfest any more regardless of whether it actually resolved the issues authoritatively. Making decisions in a consensus-driven community is just hard and we could use some lessons in how to say no or how to resolve irreconcilable conflicts but barring solving those issues it would at least be nice to remove them from the critical path blocking other patches and making the process feel interminable for bystanders. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
