Re: PostgreSQL 17 Release Management Team & Feature Freeze

On Mon, 8 Apr 2024 at 19:48, Matthias van de Meent <
boekewurm+postgres@gmail.com> wrote:

> On Mon, 8 Apr 2024 at 17:21, Tomas Vondra <tomas.vondra@enterprisedb.com>
> wrote:
> >
> >
> >
> > On 4/8/24 16:59, Tom Lane wrote:
> > > Heikki Linnakangas <hlinnaka@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.