[tz] proposal for new tzdb versions

[John Hawkinson]

Paul Eggert via tz <tz at iana.org> wrote on Wed, 22 Sep 2021
at 14:30:38 EDT in <2184234f-a2f3-7bbe-a9da-db21bbac7c71 at cs.ucla.edu>:


> In light of the previous discussions and the fact that we need a new release
> very soon, I propose the following:
> 
> * We release 2021b pretty much as-is (with the usual release administrivia
> such as updating NEWS).
> 
> * We also generate a separate 2021a1 version, which is like 2021a except
> with the Samoa change that is prompting 2021b. This version recognizes the
> concerns about the number of changes to pre-1970 timestamps in 2021b. I'll
> do this by publishing a patch to 2021a, along with a patched tarball, on my
> website at UCLA.

I don't understand why we would release 2021b as-proposed. What is the timliness that requires doing that?

Making that release will make it *far* more difficult to undo, when most downstream consumers adopt it.

It effectively pretermits the discussion we are having.
I think it is imprudent, unwise, and a bit unfair.


I had drafted some comments from the back of my brain on Monday, and never made them coherent, but perhaps here's the time to offer them, imperfect as they remain: The practice of making commits to the master source control repository for the release branch of the project while simultaneously characterizing them as “experimental" is a big part of the problem of how we got here. It confers a massive first-mover advantage to those commits, which have not necessarily had the benefit of conensus (indeed, it seems often they are committed and then concensus is sought after).

This is not reasonable, and it means that any release cut from the repo can (and apparently will) contain experimental changes that are unvetted and do not hold conensus. Those kinds of changes ought to be made on another branch, not the branch from which releases are cut.

--
jhawk at alum.mit.edu
John Hawkinson