[tz] Tonga returns to DST on 2016-11-06

Brian Inglis Brian.Inglis at SystematicSw.ab.ca
Fri Nov 4 19:20:16 UTC 2016


On 2016-11-04 12:06, Paul G wrote:
> On November 4, 2016 1:43:26 PM EDT, Brian Inglis wrote:
>> On 2016-11-03 16:08, Paul Eggert wrote:
>>> On 11/02/2016 09:57 AM, Deborah Goldsmith wrote:

>>>> I know it’s checked into the informal GitHub repository. That
>>>> doesn’t work for everyone.

>>> Now that we have an official release with the Tonga changes, your
>>> developers should be OK to run with it.
>>> Why doesn't the GitHub development repository work for them? Are
>>> there technical problems with using Git or GitHib? Or is this more a
>>> case of not using the data until it's "blessed" somehow? Either way,
>>> there should be some way to address the problem other than by having
>>> your folks wait impatiently for tarballs to show up at iana.org <http://iana.org>.

>> With processes checking if a new release has been packaged or announced
>> and sources have been updated and tagged, kicking off the download,
>> build, test, package, release, announce cycle, you need a reliable flag
>> or flags to kick off the process, which could be one, more, or all of
>> the above checks.
>> Triggering on just any change in the remote GitHub repo, which does see
>> a fair amount of churn many months, may not be acceptable, where it may
>> be with projects in local repos using Continuous Integration processes.
>> Changing one of these production processes in any org is not likely to
>> be a lightweight undertaking, and involve spending budget on process
>> change development and testing, where it may be considered better spent
>> on more pressing significant current problems.
>> Personally, a cron job checks daily if IANA ...latest symlinks contain
>> a version differing from the last download, then downloads, archives,
>> diffs, builds, compares, installs, and emails a file:// link to the log,
>> to let me know something (attempted to be) changed.

> I think Paul meant that the "official" release would be the act of
> tagging the repo with the new version, not any random change.

I know he does, but this is not documented anywhere, and he changed
where the version is found, and that is not documented anywhere, whereas
the IANA process is documented in an RFC.

Companies are unlikely to change their processes unless changes break
existing processes (like the version change) or changes are documented
in an RFC, which can be presented to SOx auditors and their ilk, to
document and justify why they spent money and changed a process, along
with the documentation on change impact including budget, authorizations,
and the dozens of other side efforts of production changes, summarized
above by DG as "That doesn’t work for everyone."

It may work for you or me if we really need an update ASAP, or Joe
Blow's Cowboy Coding Shop over by, but not for most public companies;
private companies and governments tend to be even cheaper and/or more
bureaucratic about spending money or effort on "unnecessary changes".

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada


More information about the tz mailing list