Re: PostgreSQL 17 Release Management Team & Feature Freeze

From: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
To: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
Cc: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Robert Haas <robertmhaas(at)gmail(dot)com>, 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 19:32:14
Message-ID: CAGECzQRgH_s-MCBqN70ObyYfoR096_EsTq0XrdnYRj5QYiNeCQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 8 Apr 2024 at 20:15, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> wrote:
> I 100% understand how frustrating the lack of progress can be, and I
> agree we need to do better. I tried to move a number of stuck patches
> this CF, and I hope (and plan) to do more of this in the future.
>
> But I don't quite see how would this rule modification change the
> situation for non-committers.

The problem that I feel I'm seeing is that committers mostly seem to
materially review large patchsets in the last two commit fests. This
might be not based in reality, but it is definitely how it feels to
me. If someone has stats on this, feel free to share.

I'll sketch a situation: There's a big patch that some non-committer
submitted that has been sitting on the mailinglist for 6 months or
more, only being reviewed by other non-committers, which the submitter
quickly addresses. Then in the final commit fest it is finally
reviewed by a committer, and they say it requires significant changes.
Right now, the submitter can decide to quickly address those changes,
and hope to keep the attention of this committer, to hopefully get it
merged before the deadline after probably a few more back and forths.
But this new rule would mean that those significant changes would be a
reason not to put it in the upcoming release. Which I expect would
first of all really feel like a slap in the face to the submitter,
because it's not their fault that those changes were only requested in
the last commit fest. This would then likely result in the submitter
not following up quickly (why make time right at this moment, if
you're suddenly going to have another full year), which would then
cause the committer to lose context of the patch and thus interest in
the patch. And then finally getting into the exact same situation next
year in the final commit fest, when some other committer didn't agree
with the redesign of the first one and request a new one pushing it
another year.

So yeah, I definitely agree with Matthias. I definitely feel like his
rule would seriously impact contributions made by non-committers.

Maybe a better solution to this problem would be to spread impactful
reviews by committers more evenly throughout the year. Then there
wouldn't be such a rush to address them in the last commit fest.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2024-04-08 19:47:34 post-freeze damage control
Previous Message Daniel Gustafsson 2024-04-08 19:29:40 Converting README documentation to Markdown