Re: Last gasp

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Last gasp
Date: 2012-04-07 22:51:22
Message-ID: 10357.1333839082@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Geoghegan <peter(at)2ndquadrant(dot)com> writes:
> On 7 April 2012 22:20, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2012-04-07 22:53:06 Re: Last gasp
Previous Message Peter Geoghegan 2012-04-07 22:33:16 Re: Last gasp