Re: PostgreSQL 17 Release Management Team & Feature Freeze

From: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
To: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
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 22:34:10
Message-ID: 6ef2b1f1-63a7-4d4e-ba72-33b27c2589ab@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 4/8/24 21:32, Jelte Fennema-Nio wrote:
> 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.
>

FWIW I have no doubt this problem is very real. It has never been easy
to get stuff reviewed/committed, and I doubt it improved in last couple
years, considering how the traffic on pgsql-hackers exploded :-(

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

Right. I think that's mostly what I was aiming for, although I haven't
made it very clear/explicit. But yeah, if the consequence of the "rule"
was that some of the patches are neglected entirely, that'd be pretty
terrible - both for the project and for the contributors.

regards

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2024-04-08 22:50:05 Re: PostgreSQL 17 Release Management Team & Feature Freeze
Previous Message David Rowley 2024-04-08 22:23:28 Re: enhance the efficiency of migrating particularly large tables