Re: PostgreSQL 17 Release Management Team & Feature Freeze

Поиск
Список
Период
Сортировка
От Jelte Fennema-Nio
Тема Re: PostgreSQL 17 Release Management Team & Feature Freeze
Дата
Msg-id CAGECzQRgH_s-MCBqN70ObyYfoR096_EsTq0XrdnYRj5QYiNeCQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PostgreSQL 17 Release Management Team & Feature Freeze  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Ответы Re: PostgreSQL 17 Release Management Team & Feature Freeze  (Robert Haas <robertmhaas@gmail.com>)
Re: PostgreSQL 17 Release Management Team & Feature Freeze  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Re: PostgreSQL 17 Release Management Team & Feature Freeze  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
On Mon, 8 Apr 2024 at 20:15, Tomas Vondra <tomas.vondra@enterprisedb.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.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Daniel Gustafsson
Дата:
Сообщение: [MASSMAIL]Converting README documentation to Markdown
Следующее
От: Robert Haas
Дата:
Сообщение: [MASSMAIL]post-freeze damage control