Subject: Re: PostgreSQL 17 Release Management Team & Feature Freeze

From: Andres Freund <[email-masked]>
Date: Mon, 8 Apr 2024 08:29:48 -0700

Hi,

On 2024-04-08 09:26:09 -0400, Robert Haas wrote:
> On Sun, Apr 7, 2024 at 6:50 PM Michael Paquier <[email-masked]> 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.

Greetings,

Andres

---

From: "Jonathan S. Katz" <[email-masked]>
Date: Mon, 8 Apr 2024 12:23:14 -0400

> 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

---

From: Masahiko Sawada <[email-masked]>
Date: Tue, 9 Apr 2024 01:34:09 +0900

On Tue, Apr 9, 2024 at 12:30 AM Andres Freund <[email-masked]> wrote:
> Some will just polish commits until the last minute, until the
> entries until the freeze is reached, others will push half baked stuff.

I agree with this part.

Aside from considering how to institute some rules for mitigating the
last-minute rush, it might also be a good idea to consider how to
improve testing the new commits during beta. FWIW in each year, after
feature freeze I personally pick some new features that I didn't get
involved with during the development and do intensive reviews in
April. It might be good if more people did things like that. That
might help finding half baked features earlier and improve the quality
in general. So for example, we list features that could require more
reviews (e.g. because of its volume, complexity, and a span of
influence etc.) and we do intensive reviews for these items. Each item
should be reviewed by other than the author and the committer. We may
want to set aside a specific period for intensive testing.

Regards,

-- 
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com