Re: PostgreSQL 17 Release Management Team & Feature Freeze

On 4/8/24 16:59, Tom Lane wrote:
> Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
>> On 08/04/2024 16:43, Tom Lane wrote:
>>> 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.
>
>> Can you elaborate, which patches you think were not ready? Let's make
>> sure to capture any concrete concerns in the Open Items list.
>
> [ shrug... ] There were fifty-some commits on the last day,
> some of them quite large, and you want me to finger particular ones?
> I can't even have read them all yet.
>
>> 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.
>
> Perhaps something like that could help, but it seems like a lot
> of mechanism. I think the real problem is just that committers
> need to re-orient their thinking a little. We must get *less*
> willing to commit marginal patches, not more so, as the deadline
> approaches.
>

For me the main problem with the pre-freeze crush is that it leaves
pretty much no practical chance to do meaningful review/testing, and
some of the patches likely went through significant changes (at least
judging by the number of messages and patch versions in the associated
threads). That has to have a cost later ...

That being said, I'm not sure the "progressive deadline" proposed by
Heikki would improve that materially, and it seems like a lot of effort
to maintain etc. And even if someone updates the CF app with all the
details, does it even give others sufficient opportunity to review the
new patch versions? I don't think so. (It anything, it does not seem
fair to expect others to do last-minute reviews under pressure.)

Maybe it'd be better to start by expanding the existing rule about not
committing patches introduced for the first time in the last CF. What if
we said that patches in the last CF must not go through significant
changes, and if they do it'd mean the patch is moved to the next CF?
Perhaps with exceptions to be granted by the RMT when appropriate?

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company