Re: PostgreSQL 17 Release Management Team & Feature Freeze - Mailing list pgsql-hackers

From Jonathan S. Katz
Subject Re: PostgreSQL 17 Release Management Team & Feature Freeze
Date
Msg-id 79c95401-d8ab-487d-9d25-36243b851ae7@postgresql.org
Whole thread Raw
In response to Re: PostgreSQL 17 Release Management Team & Feature Freeze  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On 4/8/24 8:29 AM, Andres Freund wrote:
> Hi,
> 
> On 2024-04-08 09:26:09 -0400, Robert Haas wrote:
>> On Sun, Apr 7, 2024 at 6:50 PM Michael Paquier <michael@paquier.xyz> 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.
> 
> I don't think it's very useful to paint a very broad brush here,
> unfortunately. Some will just polish commits until the last minute, until the
> the dot's on the i's really shine, others will continue picking up more CF
> entries until the freeze is reached, others will push half baked stuff.  Of
> course there will be an increased commit rate, but it does looks like there
> was some stuff that looked somewhat rickety.

I agree with Andres here (though decline to comment on the rickety-ness 
of the patches). I think overcoming human nature to be more proactive at 
a deadline is at least a NP-hard problem. This won't change if we adjust 
deadlines. I think it's better to ensure we're enforcing best practices 
for commits, and maybe that's a separate review to have.

As mentioned in different contexts, we do have several safeguards for a 
release:

* We have a (fairly long) beta period; this allows us to remove patches 
prior to GA and get in further testing.
* We have a RMT that (as Tom mentioned) can use its powers early and 
often to remove patches that are not up to our quality levels.
* We can evaluate the quality of the commits coming in and coach folks 
on what to do better.

I understand that a revert is costly, particularly the longer a commit 
stays in, and I do 100% agree we should maintain the high commit bar we 
have and not rush things in just so "they're in for feature freeze and 
we'll clean them up for beta." That's where best practices come in.

I tend to judge the release by the outcome: once we go GA, how buggy is 
the release? Did something during the release cycle (e.g. a sloppy 
commit during feature freeze, lack of testing) lead to a bug that 
warranted an out-of-cycle release? And yes, how we commit things at 
feature freeze / through the beta impact that - we should ensure we're 
still committing things that we would have committed at a least hectic 
time, but understand that the deadline is still a strong motivator co 
complete the work.

Thanks,

Jonathan

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Synchronizing slots from primary to standby
Next
From: Robert Haas
Date:
Subject: Re: PostgreSQL 17 Release Management Team & Feature Freeze