On Fri, Jan 22, 2016 at 6:21 PM, Andres Freund <andres@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
