From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, David Rowley <dgrowleyml(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Subject: | Re: PostgreSQL 17 Release Management Team & Feature Freeze |
Date: | 2024-04-09 12:27:31 |
Message-ID: | a3691704-d176-44be-a500-a2240dbe5b7a@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2024-04-08 Mo 19:26, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> I quite like the triage idea. But I think there's also a case for being
>> more a bit more flexible with those patches we don't throw out. A case
>> close to my heart: I'd have been very sad if the NESTED piece of
>> JSON_TABLE hadn't made the cut, which it did with a few hours to spare,
>> and I would not have been alone, far from it. I'd have been happy to
>> give Amit a few more days or a week if he needed it, for a significant
>> headline feature.
>> I know there will be those who say it's the thin end of the wedge and
>> rulez is rulez, but this is my view.
> You've certainly been around the project long enough to remember the
> times in the past when we let the schedule slip for "one more big
> patch". It just about never worked out well, so I'm definitely in
> favor of a hard deadline. The trick is to control the tendency to
> push in patches that are only almost-ready in order to nominally
> meet the deadline. (I don't pretend to be immune from that
> temptation myself, but I think I resisted it better than some
> this year.)
>
>
If we want to change how things are working I suspect we probably need
something a lot more radical than any of the suggestions I've seen
floating around. I don't know what that might be, but ISTM we're not
thinking boldly enough.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Matthias van de Meent | 2024-04-09 12:27:32 | Re: Parallel Recovery in PostgreSQL |
Previous Message | Ranier Vilela | 2024-04-09 12:02:55 | Re: Flushing large data immediately in pqcomm |