From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Dave Page <dpage(at)postgresql(dot)org> |
Cc: | Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PostgreSQL 8.4 development plan |
Date: | 2008-02-06 15:57:39 |
Message-ID: | 47A9D8F3.6080000@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Zeugswetter Andreas ADI SD | 2008-02-06 16:10:00 | Re: pg_dump additional options for performance |
Previous Message | Simon Riggs | 2008-02-06 15:56:19 | Re: pg_dump additional options for performance |