Heikki Linnakangas <heikki.linnakangas@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