Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rtyO4-001EPe-9x for pgsql-hackers@arkaria.postgresql.org; Mon, 08 Apr 2024 23:26:52 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rtyO2-00ECSr-A3 for pgsql-hackers@arkaria.postgresql.org; Mon, 08 Apr 2024 23:26:50 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rtyO2-00ECSi-0F for pgsql-hackers@lists.postgresql.org; Mon, 08 Apr 2024 23:26:50 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rtyNz-001eUO-DU for pgsql-hackers@lists.postgresql.org; Mon, 08 Apr 2024 23:26:49 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 438NQdTs3576013; Mon, 8 Apr 2024 19:26:39 -0400 From: Tom Lane To: Andrew Dunstan cc: Alvaro Herrera , Robert Haas , Michael Paquier , David Rowley , Postgres hackers , Heikki Linnakangas Subject: Re: PostgreSQL 17 Release Management Team & Feature Freeze In-reply-to: <74015af1-14af-4aeb-a969-012ad1964148@dunslane.net> References: <202404081607.tbumrn4qzia4@alvherre.pgsql> <74015af1-14af-4aeb-a969-012ad1964148@dunslane.net> Comments: In-reply-to Andrew Dunstan message dated "Mon, 08 Apr 2024 18:50:05 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3576011.1712618799.1@sss.pgh.pa.us> Date: Mon, 08 Apr 2024 19:26:39 -0400 Message-ID: <3576012.1712618799@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Andrew Dunstan 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.) regards, tom lane