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

Greetings,

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Also on the topic of process: 48 hours before a wrap deadline is
> *particularly* not the time to play fast and loose with this sort of
> thing. It'd have been better to wait till after this week's releases,
> so there'd at least be time to reconsider if the patch turned out to
> have unexpected side-effects.

Our typical process for changes that actually end up breaking other
things is to put things back the way they were and come up with a
better answer.

Should we have reverted the code change that caused the issue in the
first place, namely, as I understand it at least, the tz code update, to
give us time to come up with a better solution and to fix it properly?

I'll admit that I wasn't following the thread very closely initially,
but I don't recall seeing that even discussed as an option, even though
we do it routinely and even had another such case for this set of
releases. Possibly a bad assumption on my part, but I did assume that
the lack of such a discussion meant that reverting wasn't really an
option due to the nature of the changes, leading us into an atypical
case already where our usual processes weren't able to be followed.

That doesn't mean we should throw the whole thing out the window either,
certainly, but I'm not sure that between the 3 options of 'revert',
'live with things being arguably broken', and 'push a contentious
commit' that I'd have seen a better option either.

I do agree that it would have been better if intentions had been made
clearer, such as announcing the plan to push the changes so that we
didn't end up with an issue during this patch set (either from out of
date zone information, or from having the wrong timezone alias be used),
but also with feelings on both sides- if there had been a more explicit
"hey, we really need input from someone else on which way they think
this should go" ideally with the options spelled out, it would have
helped.

I don't want to come across as implying that I'm saying what was done
was 'fine', or that we shouldn't be having this conversation, I'm just
trying to figure out how we can frame it in a way that we learn from it
and work to improve on it for the future, should something like this
happen again.

Thanks,

Stephen