PostgreSQL 8.4 Development Plan

From PostgreSQL wiki

Revision as of 15:02, 22 April 2009 by Robe (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

This is a copy of the email sent to -hackers on 2008-02-06 outlining the core team's plan for attacking the 8.4 development cycle.


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:

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.

Personal tools