Re: PostgreSQL 17 Release Management Team & Feature Freeze

On Mon, 8 Apr 2024 at 17:21, Tomas Vondra <tomas.vondra@enterprisedb.com> wrote:
>
>
>
> On 4/8/24 16:59, Tom Lane wrote:
> > Heikki Linnakangas <hlinnaka@iki.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.

I don't think adding more hurdles about what to include into the next
release is a good solution. Why the March CF, and not earlier? Or
later? How about unregistered patches? Changes to the docs? Bug fixes?
The March CF already has a submission deadline of "before march", so
that already puts a soft limit on the patches considered for the april
deadline.

> 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?

I also think there is already a big issue with a lack of interest in
getting existing patches from non-committers committed, reducing the
set of patches that could be considered is just cheating the numbers
and discouraging people from contributing. For one, I know I have
motivation issues keeping up with reviewing other people's patches
when none (well, few, as of this CF) of my patches get reviewed
materially and committed. I don't see how shrinking the window of
opportunity for significant review from 9 to 7 months is going to help
there.

So, I think that'd be counter-productive, as this would get the
perverse incentive to band-aid over (architectural) issues to limit
churn inside the patch, rather than fix those issues in a way that's
appropriate for the project as a whole.