gsst...@mit.edu (Greg Stark) writes: > I would like to propose a different strategy. Instead of always > tackling all the smaller patches and leaving the big patches for last, > I would suggest we start with Hot Standby. > > In fact I would suggest as Hot Standby has already gotten a first pass > review that we consider applying it on day 1. That gets it into > everyone's development trees so they can see any suspicious code or > effects it has in their peculiar environments. It may not be perfect > but if we apply it now there's plenty of time to make improvements. > > Then we can have a regular commitfest a month or so later. Hopefully > any followon changes to Hot Standby would actually get into that > commitfest if they're relatively minor.
I could see going either way on this, either: a) Doing an as-early-as-possible CommitFest to knock off easy items that have been waiting a while, and having the *second* Fest be the one where we expect all the large, controversial items to get added (e.g. - stuff like hot standby, SEPostgreSQL), or b) Focusing on the likely-hard ones (hot standby, SE PostgreSQL) first, and deferring others to Fest #2. -- select 'cbbrowne' || '@' || 'acm.org'; http://cbbrowne.com/info/linuxdistributions.html "Everything should be built top-down, except the first time." -- Alan J. Perlis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
