On 7 April 2012 22:20, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
