Re: Alpha4 release blockers (was Re: wrapping up this CommitFest)
От | Robert Haas |
---|---|
Тема | Re: Alpha4 release blockers (was Re: wrapping up this CommitFest) |
Дата | |
Msg-id | AANLkTimkZAK-1ZycXwkuGkoob4X+nh6em+1ECNW6DyEw@mail.gmail.com обсуждение исходный текст |
Ответ на | Alpha4 release blockers (was Re: wrapping up this CommitFest) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Alpha4 release blockers (was Re: wrapping up this CommitFest)
(Robert Haas <robertmhaas@gmail.com>)
Re: Alpha4 release blockers (was Re: wrapping up this CommitFest) (Tom Lane <tgl@sss.pgh.pa.us>) Re: Alpha4 release blockers (was Re: wrapping up this CommitFest) (Andres Freund <andres@anarazel.de>) Re: Alpha4 release blockers (was Re: wrapping up this CommitFest) ("David E. Wheeler" <david@kineticode.com>) |
Список | pgsql-hackers |
Let's review where we are. On Tue, Mar 1, 2011 at 3:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > * Regression test failures from recent plpython patches. These are > affecting enough machines to make them "must fix before alpha", IMO. > There are some variations in error message wording, which are not too > terrible but also not exactly hard to fix. The python assert failure > that some Fedora machines are reporting is considerably more disturbing. I believe this is fixed by commit 4c966d920fb75a5d0366b887c2ef28e6d87c1eda, although it seems no one really understands why. > * Collation-related regression failure on buildfarm member pika. This > is clearly a bug we need to identify, but maybe we can ship the alpha > without a fix --- for one thing, getting more than one report of the > problem would be helpful. pika is still red, but it claims not to have updated in 13 days, so I'm not sure what that means. > * Collation-related changes still needed in contrib/citext. If we don't > have this done before alpha4, I'm afraid we'll have to generate a 1.1 > update script to fix it for alpha4 users. I'd just as soon not deal > with that overhead. I believe that this was fixed by commit 94be9e3f0ca9e7ced66168397eb586565bced9ca. > * Rearrange pg_proc and pg_operator comments as suggested here: > http://archives.postgresql.org/pgsql-docs/2010-10/msg00041.php > While this isn't a "must fix", the very end of a development cycle > is clearly the best time for such a patch, since at any other time > there are going to be a larger number of pending patches that would > have to be adjusted. So I'd kind of like to get this done, if I can > spare a day for it. I believe this was fixed by commits 94133a935414407920a47d06a6e22734c974c3b8 and 908ab80286401bb20a519fa7dc7a837631f20369. > * Generate alpha release notes. This is at least half a day's work > for somebody, I think, even with our fairly low standards for alpha > release notes. This is all kinds of not done, AFAIK. > There are other things I'd like to do, like review and perhaps commit > the btree_gist patch, but they're not at the level of "must fix". btree_gist was commited as 8436489c81c23af637696ac69cdaafddcc907ee1 So it seems like the only thing that is an absolute must-do is write some release notes. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Tom LaneДата:
Сообщение: Re: Extensions vs. shared procedural language handler functions
Следующее
От: Robert HaasДата:
Сообщение: Re: Alpha4 release blockers (was Re: wrapping up this CommitFest)