From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Greg Smith <greg(at)2ndQuadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Last gasp |
Date: | 2012-04-15 16:01:11 |
Message-ID: | 9214.1334505671@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> If we can do Triage Week at the beginning, that will keep out the ones
> that aren't ready and allow us to focus our attention on the ones we
> really care about.
I think there's some merit in this idea, but there needs to be time
allocated to examine all the large patches before we make any hard
go/no-go decisions. Maybe we could make such choices about two weeks
in, rather than at the very start?
Another thought is that "triage" is probably not the right image to
have here. Patches that are obviously going to be rejected altogether
are not that common, and they don't take up much time when they do show
up. Where I think we have been fooling ourselves is in failing to tell
the difference between a patch that is committable in the current fest,
versus one that is still WIP and is going to need more development time.
Now the latter category *is still deserving of review*, just as much as
the former. So even if we can correctly determine early on which
patches are WIP, it doesn't mean we should bounce them out of the fest.
But it would mean they get approached differently by the reviewers.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2012-04-15 16:12:24 | Re: Clobbered parameter names via DECLARE in PL/PgSQL |
Previous Message | Tom Lane | 2012-04-15 15:50:01 | Re: Last gasp |