Re: PostgreSQL 17 Release Management Team & Feature Freeze

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, David Rowley <dgrowleyml(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>
Subject: Re: PostgreSQL 17 Release Management Team & Feature Freeze
Date: 2024-04-08 14:42:41
Message-ID: a5485b74-059a-4ea0-b445-7c393d6fe0de@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 08/04/2024 16:43, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> 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 was just about to pen an angry screed along the same lines.
> The commit flux over the past couple days, and even the last
> twelve hours, was flat-out ridiculous. These patches weren't
> ready a week ago, and I doubt they were ready now.
>
> The RMT should feel free to exercise their right to require
> revert "early and often", or we are going to be shipping a
> very buggy release.

Can you elaborate, which patches you think were not ready? Let's make
sure to capture any concrete concerns in the Open Items list.

I agree the last-minute crunch felt more intense than in previous years.
I'm guilty myself; I crunched the "direct SSL" patches in. My rationale
for that one: It's been in a pretty settled state for a long time. There
hasn't been any particular concerns about the design or the
implementation. I haven't commit tit sooner because I was not
comfortable with the lack of tests, especially the libpq parts. So I
made a last minute dash to write the tests so that I'm comfortable with
it, and I restructured the commits so that the tests and refactorings
come first. The resulting code changes look the same they have for a
long time, and I didn't uncover any significant new issues while doing
that. I would not have felt comfortable committing it otherwise.

Yeah, I should have done that sooner, but realistically, there's nothing
like a looming deadline as a motivator. One idea to avoid the mad rush
in the future would be to make the feature freeze deadline more
progressive. For example:

April 1: If you are still working on a feature that you still want to
commit, you must explicitly flag it in the commitfest as "I plan to
commit this very soon".

April 4: You must give a short status update about anything that you
haven't committed yet, with an explanation of how you plan to proceed
with it.

April 5-8: Mandatory daily status updates, explicit approval by the
commitfest manager needed each day to continue working on it.

April 8: Hard feature freeze deadline

This would also give everyone more visibility, so that we're not all
surprised by the last minute flood of commits.

--
Heikki Linnakangas
Neon (https://neon.tech)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Melanie Plageman 2024-04-08 14:52:28 Re: PostgreSQL 17 Release Management Team & Feature Freeze
Previous Message Andrey M. Borodin 2024-04-08 14:42:39 Re: PostgreSQL 17 Release Management Team & Feature Freeze