Peter Geoghegan <peter@2ndquadrant.com> writes:
> On 7 April 2012 22:20, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> In short, the idea of strongly calendar-driven releases looks more
>> and more attractive to me the more times we go through this process.
>> If your patch isn't ready on date X, then it's not getting into this
>> release; but there'll be another bus coming along before long.
> I hope that that policy will not be applied without some degree of
> discrimination.
Sure, but ...
> I understand that this is an open-source project, and on a certain
> level it has to be that simple, because we don't have any other way of
> making contributors more conscientious about scheduling
> considerations, except of course for giving them a nudge. That said,
> all features are not equal, and clearly some are of particular
> strategic importance to the project, and as such may be worth holding
> up the release for, subject to certain parameters. Which of these
> features are worth holding the release up for is highly dependent on
> their state at the time of the final commitfest deadline. Which
> features are of strategic importance is of course a matter of opinion,
> but that's the kind of thing that we have a steering committee for,
> right?
... we have tried that approach repeatedly in the past, and it's
basically never worked. There were multiple release cycles where we
held up a release to get some "super important" feature in, and
invariably either the release was *way* later than anybody expected,
or we gave up waiting and released without it. Meanwhile, development
of anything else ground to a standstill. Check the archives and you'll
see this theme played out a number of times. We've more or less learned
not to do that, but we've never taken the plunge of setting hard feature
freeze deadlines well in advance. I'm thinking maybe we should.
As for the steering committee, core tries hard not to make technical
decisions for the project; it's better to let those emerge by consensus.
regards, tom lane
