Re: PostgreSQL 17 Release Management Team & Feature Freeze

On Mon, Apr 8, 2024 at 10:41 AM Robert Treat <rob@xzilla.net> wrote:
>
> On Mon, Apr 8, 2024 at 10:27 AM Melanie Plageman
> <melanieplageman@gmail.com> wrote:
> > On Mon, Apr 8, 2024 at 9:26 AM Robert Haas <robertmhaas@gmail.com> wrote:
> > > On Sun, Apr 7, 2024 at 6:50 PM Michael Paquier <michael@paquier.xyz> wrote:
> > > > And, as of the moment of typing this email, I get:
> > > > =# select '2024-04-08 00:00-12:00' - now() as time_remaining;
> > > >  time_remaining
> > > > -----------------
> > > >  13:10:35.688134
> > > > (1 row)
> > > >
> > > > So there is just a bit more than half a day remaining before the
> > > > feature freeze is in effect.
> > >
> > > OK, so feature freeze is now in effect, then.
> > >
> > > In the future, let's use GMT for these deadlines. There have got to be
> > > a lot more people who can easily understand when a certain GMT
> > > timestamp falls in their local timezone than there are people who can
> > > easily understand when a certain AOE timestamp falls in their local
> > > timezone.
> > >
> > > And maybe we need to think of a way to further mitigate this crush of
> > > last minute commits. e.g. In the last week, you can't have more
> > > feature commits, or more lines of insertions in your commits, than you
> > > did in the prior 3 weeks combined. I don't know. I think this mad rush
> > > of last-minute commits is bad for the project.
> >
> > What if we pick the actual feature freeze time randomly? That is,
> > starting on March 15th (or whenever but more than a week before), each
> > night someone from RMT generates a random number between $current_day
> > and April 8th. If the number matches $current_day, that day at
> > midnight is the feature freeze.
> >
>
> Unfortunately many humans are hardwired towards procrastination and
> last minute heroics (it's one reason why deadline driven development
> works even though in the long run it tends to be bad practice), and
> historically was one of the driving factors in why we started doing
> commitfests in the first place (you should have seen the mad dash of
> commits before we had that process), so ISTM that it's not completely
> avoidable...
>
> That said, are you suggesting that the feature freeze deadline be
> random, and also held in secret by the RMT, only to be announced after
> the freeze time has passed? This feels weird, but might apply enough
> deadline related pressure while avoiding last minute shenanigans.

Basically, yes. The RMT would find out each day whether or not that
day is the feature freeze but not tell anyone. Then they would push
some kind of feature freeze tag (do we already do a feature freeze
tag? I didn't think so) at 11:59 PM (in some timezone) that evening
and all commits that are feature commits after that are reverted.

I basically thought it would be a way for people to know that they
need to have their work done before April but keep them from waiting
until the actual last minute. The rationale for doing it this way is
it requires way less human involvement than some of the other methods
proposed. Figuring out how many commits each committer is allowed to
do based on past number of LOC,etc like Robert's suggestion sounds
like a lot of work. I was trying to think of a simple way to beat the
natural propensity people have toward procrastination.

But, an approach like Heikki suggested [1] with check-ins and
staggered deadlines is certainly much more principled. It just sounds
like it will require a lot of enforcement and oversight. And it might
be hard to ensure it doesn't end up being enforced only for some
people and not others. However, I suppose everyone is saying a mindset
shift is needed. And you can't usually shift a mindset with a
technical solution like I proposed (despite what Libertarians might
tell you about carbon offsets).

- Melanie

[1] https://www.postgresql.org/message-id/a5485b74-059a-4ea0-b445-7c393d6fe0de%40iki.fi