Re: PostgreSQL 17 Release Management Team & Feature Freeze - Mailing list pgsql-hackers
From | Tomas Vondra |
---|---|
Subject | Re: PostgreSQL 17 Release Management Team & Feature Freeze |
Date | |
Msg-id | f81776a3-6045-4e1b-847d-e7e08eb61286@enterprisedb.com Whole thread Raw |
In response to | Re: PostgreSQL 17 Release Management Team & Feature Freeze (Matthias van de Meent <boekewurm+postgres@gmail.com>) |
Responses |
Re: PostgreSQL 17 Release Management Team & Feature Freeze
Re: PostgreSQL 17 Release Management Team & Feature Freeze Re: PostgreSQL 17 Release Management Team & Feature Freeze |
List | pgsql-hackers |
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
pgsql-hackers by date: