Re: 8.3 pending patch queue

From: "Jim C(dot) Nasby" <decibel(at)decibel(dot)org>
To: "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>
Cc: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 8.3 pending patch queue
Date: 2007-05-16 15:36:42
Message-ID: 20070516153642.GI14548@nasby.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, May 16, 2007 at 12:33:38AM -0300, Marc G. Fournier wrote:
> Someone (you, I think) advocated a '3 weeks and then dump the rest of the
> patches' (not quote as strong of wording, but similar) ... why not split the
> patches list up:
>
> submitted patches, not reviewed
> reviewed patches, needs work, waiting on author
> reviewed patches, ready for commit.
>
> Once feature freeze started, the first list should only get small patches to
> it, easily reviewed and committed ... then, focus on reviewing list A and move
> the patch to list B or commit it ... once list A is cleared off, we go into
> Beta ... if a patch on list B gets re-submitted before Beta, it gets reviewed
> and either committed, or punt'd to the next release ...

I don't think we want to be adding anything new in beta. But if we went
into 'alpha' when list A is cleared that might work.

(BTW, it's not really clear which list "A" is...)

> That leaves Freeze -> Beta being as long as it takes to get thorugh List A ...
> and the only thing punt'd to the next release being that which really isn't
> ready ...
--
Jim Nasby decibel(at)decibel(dot)org
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim C. Nasby 2007-05-16 15:39:03 Re: Testing concurrent psql
Previous Message Dave Page 2007-05-16 15:34:56 Re: Not ready for 8.3