On Mon, 8 Apr 2024 at 19:48, Matthias van de Meent < boekewurm+postg...@gmail.com> wrote:
> On Mon, 8 Apr 2024 at 17:21, Tomas Vondra <tomas.von...@enterprisedb.com> > wrote: > > > > > > > > On 4/8/24 16:59, Tom Lane wrote: > > > Heikki Linnakangas <hlinn...@iki.fi> writes: > > >> On 08/04/2024 16:43, Tom Lane wrote: > > >>> I was just about to pen an angry screed along the same lines. > > >>> The commit flux over the past couple days, and even the last > > >>> twelve hours, was flat-out ridiculous. These patches weren't > > >>> ready a week ago, and I doubt they were ready now. > > > > > >> Can you elaborate, which patches you think were not ready? Let's make > > >> sure to capture any concrete concerns in the Open Items list. > > > > > > [ shrug... ] There were fifty-some commits on the last day, > > > some of them quite large, and you want me to finger particular ones? > > > I can't even have read them all yet. > > > > > >> Yeah, I should have done that sooner, but realistically, there's > nothing > > >> like a looming deadline as a motivator. One idea to avoid the mad rush > > >> in the future would be to make the feature freeze deadline more > > >> progressive. For example: > > >> April 1: If you are still working on a feature that you still want to > > >> commit, you must explicitly flag it in the commitfest as "I plan to > > >> commit this very soon". > > >> April 4: You must give a short status update about anything that you > > >> haven't committed yet, with an explanation of how you plan to proceed > > >> with it. > > >> April 5-8: Mandatory daily status updates, explicit approval by the > > >> commitfest manager needed each day to continue working on it. > > >> April 8: Hard feature freeze deadline > > > > > >> This would also give everyone more visibility, so that we're not all > > >> surprised by the last minute flood of commits. > > > > > > Perhaps something like that could help, but it seems like a lot > > > of mechanism. I think the real problem is just that committers > > > need to re-orient their thinking a little. We must get *less* > > > willing to commit marginal patches, not more so, as the deadline > > > approaches. > > > > > > > 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. > > 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. > I second your opinion, Mattias! I also feel that the management of the review of other contibutor's patches participation is much more important for a community as a whole. And this could make process of patches proposals and improvement running, while motivating participation (in all three roles of contributors, reviewers and committers), not vice versa. Regards, Pavel.
