PostgreSQL 8.4 development plan

On Wed, 2008-02-06 at 08:56 +0000, Dave Page wrote:

Hackers,

+1 Very much in favour.

--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com

On Wed, Feb 06, 2008 at 08:56:51AM +0000, Dave Page wrote:

Hackers,

Looks great and well-thought through. Let's hope it works out!

I assume you'll be committing this info to the developer section on the
website?

//Magnus

On Feb 6, 2008 1:49 PM, Magnus Hagander <magnus@hagander.net> wrote:

On Wed, Feb 06, 2008 at 08:56:51AM +0000, Dave Page wrote:

Hackers,

Looks great and well-thought through. Let's hope it works out!

I assume you'll be committing this info to the developer section on the
website?

It's on the developer wiki.

/D

On Wed, Feb 06, 2008 at 02:42:35PM +0000, Dave Page wrote:

On Feb 6, 2008 1:49 PM, Magnus Hagander <magnus@hagander.net> wrote:

On Wed, Feb 06, 2008 at 08:56:51AM +0000, Dave Page wrote:

Hackers,

Looks great and well-thought through. Let's hope it works out!

I assume you'll be committing this info to the developer section on the
website?

It's on the developer wiki.

Good start. /me thinks it should be on the website. We've usually announced
our feature freeze dates there... (in less details, sure, but something
there)

//Magnus

On Feb 6, 2008 2:44 PM, Magnus Hagander <magnus@hagander.net> wrote:

Good start. /me thinks it should be on the website. We've usually announced
our feature freeze dates there... (in less details, sure, but something
there)

Feel free - you've been hacking that recently!

/D

Dave Page wrote:

Hackers,

As you know we've finally released PostgreSQL 8.3, after a development
cycle that lasted well over a year despite our original plans for a 6
month cycle. The core team are aware that there are a number of
factors that contributed to this slippage:

- Lack of prompt and early review of patches.
- A significant rise in the number and complexity of patches submitted.
- Prioritising completion of incomplete patches over meeting the timetable.

In the 8.4 development cycle we would like to try a new style of
development, designed to keep the patch queue to a limited size and to
provide timely feedback to developers on the work they submit. To do
this we will replace the traditional 'feature freeze' with a series of
'commit fests' throughout the development cycle. The idea of commit
fests was discussed last October in -hackers, and it seemed to meet
with general approval. Whenever a commit fest is in progress, the
focus will shift from development to review, feedback and commit of
patches. Each fest will continue until all patches in the queue have
either been committed to the CVS repository, returned to the author
for additional work, or rejected outright, and until that has
happened, no new patches will be considered. Of course, individual
developers are free to continue working on their
patches throughout the fest, but we encourage everyone to do what they
can to help work through the patch queue. We feel that this idea can
only be successful if the whole development community is willing to
focus on patch review during the commit fests, in the same way that
everyone is expected to focus on testing during beta period.

The proposed timetable for the cycle is as follows:

1st March 2008 - commit fest begins
1st May 2008 - commit fest begins
1st July 2008 - commit fest begins
1st September 2008 - commit fest begins
1st November 2008 - final commit fest begins
1st January 2009 - beta 1
1st March 2009 - 8.4.0 release

Note the lack of any 'feature freeze' date as such. However, any
significant feature patches not submitted by 1st November will clearly
not make it into 8.4.

The hope here is that we will not have enormous, previously unreviewed
patches landing on us at the end of October --- if that happens, we'll
be back in the same position we were in at 8.3 feature freeze.
Although this schedule allows for the final commit fest to take a good
deal of time, we'll reserve the right to reject patches that are too
large to be reviewed in a timely fashion. We want to encourage people
to do development of large features in an incremental fashion, with a
new increment landing during each commit fest.

Regards, Dave (on behalf of the core team)

I would like to see this tied down some more. The time for the commit
fests is too open ended. I think we should say something like "All
commit fests will run no more than two weeks, except for the final
commit fest which can run for one month."

If we can't make that work then the whole idea is probably in trouble
anyway.

Another possibility which might help allocating reviewers to projects
(especially large projects) earlier in the process.

cheers

andrew

Am Mittwoch, 6. Februar 2008 schrieb Andrew Dunstan:

I would like to see this tied down some more. The time for the commit
fests is too open ended. I think we should say something like "All
commit fests will run no more than two weeks, except for the final
commit fest which can run for one month."

Something along those lines was discussed, but we feel that because we have no
experience with how commit fests will run, it is unwise to specify that much
detail already. It is quite possible that as we gain experience with the
process the timeline will be clarified.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

On Feb 6, 2008 3:57 PM, Andrew Dunstan <andrew@dunslane.net> wrote:

I would like to see this tied down some more. The time for the commit
fests is too open ended. I think we should say something like "All
commit fests will run no more than two weeks, except for the final
commit fest which can run for one month."

I think thats one of the problems - without knowing what patches are
going to come in, or how many there will be, we have no way of knowing
how long each fest will take. What this does mean though is that we
continuously feedback to developers and keep the patch queue down -
kinda like checkpoint smoothing I guess.

/D

This all sounds very promising.

On Feb 6, 2008 7:56 PM, Dave Page <dpage@postgresql.org> wrote:

Each fest will continue until all patches in the queue have
either been committed to the CVS repository, returned to the author
for additional work, or rejected outright, and until that has
happened, no new patches will be considered.

So does this mean we will have a new "patches awaiting the next review
cycle" queue alongside the "patches awaiting review" queue?

Just thinking that we'll need somewhere to park the new patches which
roll in during a commit fest.

Or, you know, start using an actual development tracker =)

Cheers
BJ

Dave Page wrote:

On Feb 6, 2008 3:57 PM, Andrew Dunstan <andrew@dunslane.net> wrote:

I would like to see this tied down some more. The time for the commit
fests is too open ended. I think we should say something like "All
commit fests will run no more than two weeks, except for the final
commit fest which can run for one month."

I think thats one of the problems - without knowing what patches are
going to come in, or how many there will be, we have no way of knowing
how long each fest will take. What this does mean though is that we
continuously feedback to developers and keep the patch queue down -
kinda like checkpoint smoothing I guess.

I would rather set a target and modify it if necessary based on
experience than have none at all.

The danger of not doing so is that we'll be in almost constant 'commit
fest' mode.

cheers

andrew

On Feb 6, 2008 4:24 PM, Andrew Dunstan <andrew@dunslane.net> wrote:

I would rather set a target and modify it if necessary based on
experience than have none at all.

The danger of not doing so is that we'll be in almost constant 'commit
fest' mode.

Yes, that is something we discussed, and the reason why we used the
wording 'proposed timetable for the cycle'. We will adjust the timing
if need be, but wanted to start out on a confident note :-)

/D

Dave Page wrote:

On Feb 6, 2008 4:24 PM, Andrew Dunstan <andrew@dunslane.net> wrote:

I would rather set a target and modify it if necessary based on
experience than have none at all.

The danger of not doing so is that we'll be in almost constant 'commit
fest' mode.

Yes, that is something we discussed, and the reason why we used the
wording 'proposed timetable for the cycle'. We will adjust the timing
if need be, but wanted to start out on a confident note :-)

Sometimes I wish we could decide if we want to be wishy or washy ;-)

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

I would rather set a target and modify it if necessary based on
experience than have none at all.

We felt that we'd like to get a couple of fests under our belts before
trying to nail down very many rules. The process will get more
formalized later, no doubt, but let's see what the actual problems are
before guessing about how to fix them.

The original draft listed the first commit fest as being in May, but
we added a March fest in part to have a "practice run" without too much
stuff being on the plate.

regards, tom lane

"Brendan Jurd" <direvus@gmail.com> writes:

Just thinking that we'll need somewhere to park the new patches which
roll in during a commit fest.

Bruce has always kept two patch queues, one for the current version and
one for the stuff held for the next version. This won't change anything
except the labels on the queues.

regards, tom lane

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

I would rather set a target and modify it if necessary based on
experience than have none at all.

We felt that we'd like to get a couple of fests under our belts before
trying to nail down very many rules. The process will get more
formalized later, no doubt, but let's see what the actual problems are
before guessing about how to fix them.

The original draft listed the first commit fest as being in May, but
we added a March fest in part to have a "practice run" without too much
stuff being on the plate.

OK, that makes some sense, although I don't know about the "not much
stuff on the plate". We presumably have quite a lot of stuff in the
queue from the last 7 months or so.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

Tom Lane wrote:

we added a March fest in part to have a "practice run" without too much
stuff being on the plate.

OK, that makes some sense, although I don't know about the "not much
stuff on the plate". We presumably have quite a lot of stuff in the
queue from the last 7 months or so.

There is, although I think a large fraction of it will get bounced as
"needs more work", which should reduce the pressure. We'll just be
trying to give feedback to let the patch authors move forward, which
will not take as much time as actually committing would take.

The current queue is
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
Note that a lot of the bulk is discussion of things that aren't
anywhere near committable anyway.

regards, tom lane

On Wednesday 06 February 2008 09:09, Tom Lane wrote:

"Brendan Jurd" <direvus@gmail.com> writes:

Just thinking that we'll need somewhere to park the new patches which
roll in during a commit fest.

Bruce has always kept two patch queues, one for the current version and
one for the stuff held for the next version. This won't change anything
except the labels on the queues.

I think we might want to do something along the lines of what Stefan set up
(at least I think it was he) for the end of 8.4 on developer.postgresql.org.
Bruce's patch list is easy to update, but hard to read. I'll put some effort
into it.

--
Josh Berkus
PostgreSQL @ Sun
San Francisco

The plan looks great. I am +1

Josh Berkus escribi�:

I think we might want to do something along the lines of what Stefan set up
(at least I think it was he) for the end of 8.4 on developer.postgresql.org.
Bruce's patch list is easy to update, but hard to read. I'll put some effort
into it.

Easy to update for Bruce -- for anyone else it is impossible to update
AFAIK.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.