Feedback-ID: ia2694551:Fastmail
Date: Mon, 8 Apr 2024 18:07:25 +0200
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, 
	David Rowley <dgrowleyml@gmail.com>, Postgres hackers <pgsql-hackers@lists.postgresql.org>, 
	Heikki Linnakangas <hlinnaka@iki.fi>
Subject: Re: PostgreSQL 17 Release Management Team & Feature Freeze
Message-ID: <202404081607.tbumrn4qzia4@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CA+Tgmoan3F5o4Sk4-8CTCGQDdq4zDg6MX4Wv6gQ9Fw7z8y5BBA@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/202404081607.tbumrn4qzia4%40alvherre.pgsql>
Precedence: bulk

On 2024-Apr-08, Robert Haas wrote:

> And maybe we need to think of a way to further mitigate this crush of
> last minute commits. e.g. In the last week, you can't have more
> feature commits, or more lines of insertions in your commits, than you
> did in the prior 3 weeks combined. I don't know. I think this mad rush
> of last-minute commits is bad for the project.

Another idea is to run a patch triage around mid March 15th, with the
intention of punting patches to the next cycle early enough.  But rather
than considering each patch in its own merits, consider the responsible
_committers_ and the load that they are reasonably expected to handle:
determine which patches each committer deems his or her responsibility
for the rest of that March commitfest, and punt all the rest.  That way
we have a reasonably vetted amount of effort that each committer is
allowed to spend for the remainder of that commitfest.  Excesses should
be obvious enough and discouraged.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/