Re: PostgreSQL 17 Release Management Team & Feature Freeze

On 4/8/24 17:48, Matthias van de Meent wrote:
> On Mon, 8 Apr 2024 at 17:21, Tomas Vondra <tomas.vondra@enterprisedb.com> wrote:
>>
>> ...
>>
>> 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.
> 

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. AFAIK we already have the rule that
(complex) patches should not appear in the last CF for the first time,
and I'd argue that a substantial rework of a complex patch is not that
far from a completely new patch. Sure, the reworks may be based on a
thorough review, so there's a lot of nuance. But still, is it possible
to properly review if it gets reworked at the very end of the CF?

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

Surely those architectural shortcomings should be identified in a review
- which however requires time to do properly, and thus is an argument
for ensuring there's enough time for such review (which is in direct
conflict with the last-minute crush, IMO).

Once again, I 100% agree we need to do better in handling patches from
non-committers, absolutely no argument there. But does it require this
last-minute crush? I don't think so, it can't be at the expense of
proper review and getting it right. A complex patch needs to be
submitted early in the cycle, not in the last CF. If it's submitted
early, but does not receive enough interest/reviews, I think we need to
fix & improve that - not to rework/push it at the very end.


regards

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