Magnus Hagander <magnus@hagander.net> writes:
> On Jan 20, 2016 5:03 PM, "Andres Freund" <andres@anarazel.de> wrote:
>> FWIW, looking at the last few commitfests, aside heroic and
>> unsustainable efforts by individual CF managers, I haven't noticed any
>> effect of when fests started/stopped. Aside from a short time increase
>> in unfinished patches being posted the day before the next CFs starts.
> Yeah, we seem to be firmly stuck at two month long commitfests started
> every two months. The plan was for them to be one month..
> Maybe we should try just very drastically cutting them at one month and
> bumping everything left. No questions asked, no extra time for anybody.
> Regardless of if it's the first or the last commitfest.
> Just to see what happens. Because what we are doing now clearly doesn't
> work..
I do not think commitfest length is the problem (though surely it's not
working as intended). What happened with 9.5 is we forked the 9.6
development branch on June 30th, with the expectation of releasing in
September, and then couldn't release in September because nobody had done
any significant amount of stabilization work. Instead we had the 2015-07
commitfest. And the 2015-09 commitfest. And the 2015-11 commitfest.
We will not get back to on-schedule releases unless we can keep -hackers
working on release testing/stabilization when it's time to do that,
rather than being distracted by shiny new stuff going into the next
release.
I'd suggest that the easiest process fix is to not fork a new devel branch
until we reach, say, RC status.
And that does mean losing at least one commitfest per release cycle ---
but it would be the currently-first one, not the currently-last one.
regards, tom lane
