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