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)
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 |