Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)

Greetings,

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> On Thu, Jun 20, 2019 at 1:28 PM Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
> > I suppose we could have a moratorium on commits starting from (say) EOB
> > Wednesday of the week prior to the release; patches can only be
> > committed after that if they have ample support (where "ample support"
> > might be defined as having +1 from, say, two other committers). That
> > way there's time to discuss/revert/fix anything that is deemed
> > controversial.
>
> Or we could have a moratorium on any change at any time that has a -1
> from a committer and a +1 from nobody.

What about a change that's already been committed but another committer
feels caused a regression? If that gets a -1, does it get reverted
until things are sorted out, or...?

In the situation that started this discussion, a change had already been
made and it was only later realized that it caused a regression. Piling
on to that, the regression was entwined with other important changes
that we wanted to include in the release.

Having a system where when the commit was made is a driving factor seems
like it would potentially reward people who pushed a change early by
giving them the upper hand in such a discussion as this.

Ultimately though, I still agree with Andres that this is something we
should act to avoid these situation and we shouldn't try to make a
policy to fit what's been a very rare occurance. If nothing else, I
feel like we'd probably re-litigate the policy every time since it would
likely have been a long time since the last discussion of it and the
specific circumstances will always be at least somewhat different.

Thanks,

Stephen