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.
> Stretching out release cycles to get in those last few neat features
> just increases the pressure for more of the same, because people don't
> know how long it will be to the next release.
I hope that that policy will not be applied without some degree of
discrimination.
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?
Perhaps a good compromise would be to formalise the process through
which patches get a second chances in the final commitfest. I don't
think that it will prove workable to have a final deadline that is
adhered to blindly.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
