Re: [CORE] RC1 blocker issues

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [CORE] RC1 blocker issues
Дата
Msg-id 9776.1164488321@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [CORE] RC1 blocker issues  ("Marc G. Fournier" <scrappy@hub.org>)
Ответы Re: [CORE] RC1 blocker issues  ("Marc G. Fournier" <scrappy@hub.org>)
Re: [CORE] RC1 blocker issues  (Andrew Sullivan <ajs@crankycanuck.ca>)
Re: [CORE] RC1 blocker issues  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
"Marc G. Fournier" <scrappy@hub.org> writes:
> As rare as he and I agree ... I agree ... LISA is nice and all, but
> end product *is* more important then timing, unless you are Microsoft,
> of course :)

I'm not concerned about announcing at LISA (though I know Josh is) ...
but at the same time I want to get the thing out the door.  I'm not sure
that anything will be gained by further delay.

This has been sort of a weird beta period, because it's the first one
we've had where cleaning up portability problems has been a complete
non-issue.  The buildfarm has changed the rules of the game that way.
Previously we've always had to allocate a fair amount of time for
getting and dealing with port reports, but I don't think we need to
do that anymore.  So really the release decision is down to "at what
point do we think it's stable enough to call it a release?".

I think we're at that point already: I just looked through the CVS logs,
and by my count there were 40 non-cosmetic patches applied to the main
source tree (not doc/ or contrib/) during the past month.  Of these
all but three either were or could have been applied to 8.1 as well,
ie, they fixed problems that exist in 8.1 or before.  The three actual
new-in-8.2 bugs found in the last thirty days are:

2006-11-10 13:10  tgl
* backend/catalog/information_schema.sql: Fix errors inkey_column_usage.position_in_unique_constraint column
recentlyaddedto information_schema (per a SQL2003 addition).  The originalcoding failed if a referenced column
participatedin more than onepg_constraint entry.  Also, it did not work if an FK relieddirectly on a unique index
withoutany constraint syntactic sugar--- this case is outside the SQL spec, but PG has always supportedit, so it's
reasonablefor our information_schema to handle it too.Per bug#2750 from Stephen Haberman.
 

2006-11-10 17:59  tgl
* backend/utils/adt/ruleutils.c: Fix pg_get_serial_sequence(),which could incorrectly return the name of an index on a
serialcolumn,rather than the name of the associated sequence.  Falloutfrom recent changes in dependency setup for
serials. Per bug #2732from Basil Evseenko.
 

2006-11-24 16:18  tgl
* backend/catalog/system_views.sql, backend/utils/adt/genfile.c,include/catalog/catversion.h,
include/catalog/pg_proc.h,test/regress/expected/rules.out:Change pg_stat_all_tables andsister views to put the
recently-addedvacuum/analyze timestampcolumns at the end, rather than at a random spot in the middle asin the original
patch.

That last one barely even qualifies as a bug; it's a cosmetic
improvement.  So it's now a solid two weeks since we found a real new bug.

So if you ask me, we are past the point of diminishing returns for the
current level of testing.  Putting out an RC might draw the attention of
a few more people, but really the only way we are going to find more
bugs is to put out a release.  Or perhaps knock heads together a little
harder on pgsql-hackers to make people think less about 8.3 development
and more about 8.2 testing, but how successful is that likely to be?
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: [CORE] RC1 blocker issues
Следующее
От: "Marc G. Fournier"
Дата:
Сообщение: Re: [CORE] RC1 blocker issues