Development Plans - Mailing list pgsql-hackers

I'm giving a talk next week on PostgreSQL 8, so I would like some input
from the community on a few issues, so that my answers are as close to
majority opinion as possible.

One of the most frequent set of questions I get asked is around the
development vision and release strategy of PostgreSQL.

- When is the next release due?
- What will be in release 8.1?
- What are you working towards? Performance? Stability? X?

These are all good questions, you'll note. They mostly indicate that the
person asking the question has already got the more basic messages, and
are preparing themselves to fully accept PostgreSQL as the way forward
*for them*.

I think I've come to understand the answers to many of these questions,
but these answers are not written down. When I do answer them, I try to
make it clear that I present a personal opinion only - but that always
gets strange looks. People really do not understand why there is no
official answer, and take that as a black mark.
Other projects such as Ubuntu, Fedora and OpenOffice have much of this
type of information easily available - certainly commercial software
vendors spend a good deal of time on providing this information.
Could we find a way of expressing the project philosophy in writing, so
I can convey that message out to the world, exactly as intended, without
any Riggs filtering?

My own understandings would be...

- When is the next release due?
I'm happy with the Zen approach of "there is no answer, the code comes
when it is time" and "HACKERS list IS the process".
Many people take the lack of a planned release date as clear indication
that there is no strictly controlled release process, however-much I
state that there really is one. In the absence of release dates, could
we write down some indication of what the release process is, so
everybody understands there is one.
My understanding is:
- new release forked in code repository
- feature freeze, beta phase starts
- string freeze, to allow translations
- release candidate process
- release
Right now, I have zero idea which quarter, let alone which month feature
freeze for 8.1 is in. I think it will be in 2005, but I'm not sure.
[That makes it fairly difficult to get sponsorship for release of new
features, since I cannot guarantee which year they'll be in.]

- what will be in release 8.1?
The TODO list contains a partial mechanism for recording what is being
worked upon by various people. Could that process by beefed up somewhat,
so there is a clear list of Features in Next Release, as part of the
TODO list on the main web site? A caveat could easily warn that this is
a provisional list only and offers no guarantees of inclusion.
I'm happy to make certain commitments to particular features already on
the TODO list. I'm sure others are too.

- What are you working towards? Performance? Stability? X?
When I explain that the pace of development has increased, people
immediately ask which direction things are going in.
In the run-up to r8.0, PITR was listed as an URGENT feature. This gave
some indication of the direction that Core wished the code base to
travel in and gave many a strong indication that they understood the
momentum and trajectory of development.
That section has been removed now.
This is a more difficult one to answer, especially since it really
covers what the major sponsors want.

I'm fairly clear about my own directions: Enterprise features to enhance
robustness, performance and scalability, plus Data Warehousing features
- nearly all of which come from clients or interested parties.
Does anybody else wish to share theirs?

Just so it is clear, there is not a single criticism on this page from
me; I am merely passing on a pattern that I think I see emerging from a
variety of conversations with clients, course attendees and
press/exhibition contacts.

Many thanks,

Best Regards, Simon Riggs