gsstark@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
