From: | Jesper Pedersen <jesper(dot)pedersen(at)comcast(dot)net> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
Cc: | 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:00:04 |
Message-ID: | 57b99dc5-71a5-441f-b84a-e2f6f9312dfb@comcast.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 4/8/24 14:15, Tomas Vondra wrote:
>I think we need to
> fix & improve that - not to rework/push it at the very end.
>
This is going to be very extreme...
Either a patch is ready for merge or it isn't - when 2 or more
Committers agree on it then it can be merged - the policy have to be
discussed of course.
However, development happens all through out the year, so having to wait
for potential feedback during CommitFests windows can stop development
during the other months - I'm talking about non-Committers here...
Having patches on -hackers@ is best, but maybe there is a hybrid model
where they exists in pull requests, tested through CfBot, and merged
when ready - no matter what month it is.
Pull requests could still have labels that ties them to a "CommitFest"
to "high-light" them, but it would make it easier to have a much clearer
cut-off date for feature freeze.
And, pull request labels are easily changed.
March is seeing a lot of last-minute changes...
Just something to think about.
Best regards,
Jesper
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2024-04-08 19:29:40 | Converting README documentation to Markdown |
Previous Message | Jeff Davis | 2024-04-08 18:55:04 | Re: Improve eviction algorithm in ReorderBuffer |