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'd imagine that clear deadlines may provide the impetus necessary to get patches in earlier, patches updated more promptly, enthuse patch-writers to lobby for review, and overall make commitfests a bit more manageable. And I'd be *strongly* against any relaxing of the current review process, and I don't think it's realistic for PostgreSQL. I want cool new features to get in as much as anyone, but if there are genuine concerns, those features really aren't yet ready for prime time. A perfect example of this is command triggers (now known as event triggers), where the feature that would have got committed wouldn't have been as flexible, elegant or sane as the feature that probably will get committed in 9.3, and I think there's plenty of outstanding questions around it too. There wouldn't be enough room for movement if the design needed anything beyond tweaking, and being painted into a corner would be depressing for all concerned. -- Thom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
