Re: Last gasp

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

In response to

Responses

Browse pgsql-hackers by date

  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