[tz] Estimate for a new tzdb release with Brazil rules.
Robert Elz
kre at munnari.OZ.AU
Thu May 16 10:55:44 UTC 2019
Date: Wed, 15 May 2019 13:52:15 -0700
From: Paul Eggert <eggert at cs.ucla.edu>
Message-ID: <342b30cb-efa9-82cc-7cd9-81d67d528387 at cs.ucla.edu>
| I'm sure Robert could do that, but I assume he doesn't want to bother.
That's right - I have something of an aversion to git.
(And for Chris, no, it is not just not in my path, it is
not installed, and is not going to be.)
| I don't know which version-control system he used (if any) when he
| maintained tzdata (2011l through 2012c).
"maintained" is a stretch, I was just acting as temporary caretaker.
RCS (I still have those files if they're of any use). There's no real
need for anything distributed, it was, and still is, maintained by one
person. All use of a DVCS is giving you is a way to avoid making
releases as many people can simply fetch it that way.
Doing real releases when needed is still the right thing to do - the
current aversion to that, in all kinds of projects, is annoying.
We ought to have had a new release a while ago so we can stop distributing
bad data for Palestine.
Further, since we got lots of advance notice of the Brazil change, which
is what we always say we want, we should be providing positive feedback
for that good behaviour by making sure that all distributors have the
best possible chance of making the updated rules available long before
they are to take effect, so when that happens it will be as seamless as
possible, and perhaps act as an example for others how to manage things
to avoid needless disruption.
Doing a release should be trivial (at least compared to verifying data
updates and then making sure they are translated into zoneinfo rule format
correctltly, and then verifying the result is what is expected - which
all happens now, and very quickly). Releases could even be automated,
to happen once a week (or whatever), if the data has altered (as
demonstrated by zic producing a set of zoneinfo files that are not
identical to the last release). That could be run out of cron, and
so add no workload at all.
kre
More information about the tz
mailing list