Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> writes: > Not really, except maybe started 6 months too late. Big patches simply take a > long time to mature. > > Looking back at the timeline for hot standby, it doesn't look unreasonable at > all: > > September: First discussion about the user-visible behavior, transaction > isolation etc.
Is that right? I had the impression Simon had started working on it previously. If so then given that feature freeze was scheduled to be November 1st starting in September does seem like it was more than a bit unrealistic. Large patches should really be targeted towards the *first* commitfest of the cycle, not the last. Targeting the last is putting all your eggs in one basket as far as getting everything right the first time. Someone else asked why this works for Linux. The reason it works is because work is *always* committed early in the release cycle. The first couple weeks of the release cycle are the *only* time significant patches are taken. The entire rest of the cycle is spent in feature freeze with development happening exclusively on subsystem maintainer's private branches. When the next release cycle begins subsystem maintainers send up patches for all the changes that have happened since the last cycle that they think are ready for release. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
