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'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
