Re: PostgreSQL 17 Release Management Team & Feature Freeze

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(at)paquier(dot)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