On Fri, 2005-02-25 at 05:34, Simon Riggs wrote:
> 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.]
>
As Marc stated, core has decided on a 12 month development cycle, so
that might look like January of next year. If I were speaking to
someone looking to sponsor development, I would tell them they would
need to being work in Q4 of 2005 at the very latest to have a chance of
something going in. As far as when they can expect to see it in a
released branch, Q2 of 2006 would probably be a reasonable estimate.
(I'm hopeful that beta wont take as long this time around since win32
should be more stable and the buildfarm should also be of some help, but
I can't imagine we'd get through it in less than 3 months)
--- update ---
Was just about to hit "send" on this email when I saw Tom's post come up
on -hackers talking about a 6 month cycle... so maybe all of the above
is off...
> - 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.
>
Actually the TODO list is really only a good indicator of things already
in the code... to get an idea of items being discussed you really just
have to hang out on the lists to see what people are working on. A list
of some of what are probably the "big things" being worked on for 8.1
include:
* Improved Resource Managment (this encapsulates the buffer manager
changes and arc replacement and similar work)
* Integrated pg_autovacuum
* Stored procedures (with transaction control and multiple result sets
among other features, not to be confused with function support)
* SQL compatible recursive WITH statements
* 2 Phase Commit
As always none of that stuff is guaranteed but those items have someone
who has stated they want to "make it happen" for 8.1 (and by make it
happen I mean they plan to code it) There are a couple of other big
things floating out there too (bitmapped indexes are a good example),
but I think those are the most concrete. There are also some things that
are cool but probably not big things (OS/2 support for instance)
> - 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 would agree that since we have a number of commercial developers who
do have intentions of working on specific items in 8.1, it would be nice
to list those items somewhere (the urgent section of the TODO seems
fine), but it is up to those developers to speak up.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
