> If people on core had come to the idea that we needed to build in
> replication *before* 8.3 came out, they certainly didn't announce it.
>
> Now is a great time to mention this because it gives everybody time to:
>
> 1. Come to a consensus on what the out-of-the-box replication should
> be, and
>
> 2. Build, test and debug whatever the consensus out-of-the-box
> replication turns out to be.
None of that is an argument for why this has to go in 8.4.
I argued in Ottawa that the idea that you have to plan a feature for
_the next release_ is getting less tenable with each release. This is
because major new features for Postgres are now often big and
complicated. The days of big gains from single victories are mostly
over (though there are exceptions, like HOT). Postgres is already
mature. As for the middle-aged person with a mortgage, longer-term
planning is simply a necessary part of life now.
There are two possibilities here. One is to have huge releases on
much longer timetables. I think this is unsustainable in a free
project, because people will get bored and go away if they don't get
to use the results of their work in a reasonably short time frame.
The other is to accept that sometimes, planning and development for
new features will have to start a long time before actual release --
maybe planning and some coding for 2 releases out. That allows large
features like the one we're discussing to be developed responsibly
without making everything else wait for it.
A
--
Andrew Sullivan
ajs@commandprompt.com
+1 503 667 4564 x104
http://www.commandprompt.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
No comments:
Post a Comment