Re: 8.4 open items list

On Thu, Mar 26, 2009 at 10:11 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> Hmm, well, Tom dropped a filtered version of your list into the open
>> items wiki page.
>>
>> http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items
>>
>> That includes a whole slough of patches that weren't submitted until
>> after November 1st and which I think should probably be bumped en
>> masse to 8.5:
>>
>> Change behavior of statement-level triggers for inheritance cases?
>> GetCurrentVirtualXIDs() (is this patch safe?)
>> PQinitSSL broken in some use cases
>> postgresql.conf: patch to have ParseConfigFile report all parsing
>> errors, then bail
>> small but useful patches for text search
>> Additional DTrace Probes
>> pg_standby trigger behavior is dangerous
>> psql \d commands and information_schema (already in CommitFest 2009-First)
>> Have \d show child tables that inherit from the specified parent
>> (already in CommitFest 2009-First)
>
> Wow, that is a large list.  Getting this all on a wiki is really what
> needed to happen.  I can't keep an open list current enough to be
> useful.

Ah, glad you like. I thought you'd been arguing the other side of
that point with me for several days, but no matter - it seems like we
might be converging on some kind of consensus here.

>> I think we should also boot everything in the "pre-existing bugs"
>> category, and the first two items from the "questions" category, which
>> don't seem important enough to worry about at this stage of the game.
>> That would leave us with 14 items, all of which look reasonably
>> relevant and 8.4-related.
>
> I think pushing "pre-existing bugs" to 8.5 is a mistake, first from a
> software quality standpoint, and second because we are going to have a
> lots of downtime during beta while we wait for feedback, so we can work
> on some of these issues then.  These things are not going to be any
> easier to fix during 8.5 than now so let's make 8.4 as good as we can
> without overly-delaying it.

What is the threshold for "has to be fixed before we can go to beta"
versus "has to be fixed before release"? I'm not opposed to fixing
the bugs, but it seems like every day that we postpone cutting a beta
is one more day until release, and so I think our immediate goal
should be to fix all of the things that need to be fixed before beta
can start.

...Robert