From: | Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com> |
---|---|
To: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
Cc: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, 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 15:56:44 |
Message-ID: | CALT9ZEEEYXm6Z-HcHz+ETC00dihE4LUmxdtbTZTfJKJF9D3eHw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 8 Apr 2024 at 19:48, Matthias van de Meent <
boekewurm+postgres(at)gmail(dot)com> wrote:
> On Mon, 8 Apr 2024 at 17:21, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
> wrote:
> >
> >
> >
> > On 4/8/24 16:59, Tom Lane wrote:
> > > Heikki Linnakangas <hlinnaka(at)iki(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2024-04-08 16:07:25 | Re: PostgreSQL 17 Release Management Team & Feature Freeze |
Previous Message | Robert Haas | 2024-04-08 15:53:48 | Re: pgsql: Fix the intermittent buildfarm failures in 040_standby_failover_ |