I think Deb Goldsmith is right and the tz db needs to change its release dynamics, which could happen in a few ways. But it could also improve the documentation of the release dynamics. I think we should hope that tzdist can get deployed before major vendors find a "magic bullet" to speed up their OS releases. As such, it's not compelling at this juncture (with tzdist around the corner?) to ask vendors to do that -- even if it were possible, which I think it really isn't. Paul Eggert <eggert@cs.ucla.edu> wrote on Fri, 10 Jul 2015 at 00:05:57 -0700 in <559F6ED5.6040701@cs.ucla.edu>:
If these delays cause problems for you, it's reasonable to use the unofficial repository at <https://github.com/eggert/tz> as a basis for operating system patches. That is, users of the tz database have a choice of either a bleeding edge unofficial version that is more up-to-date but is also more likely to contain errors, or a more-stable official version that may not have the very latest experimental changes but should work well for those who keep reasonably up-to-date with the official version.
This seems to me to be somewhat of a fiction, and to me an unhealthy one. It is not the "unofficial repository." It is the "development repository from which releases are made." We (those of us on this list) should probably all be reviewing commits to the repo in realtime and vendors should be encouraged to pull releases from it; at least if there are no other significant changes to release dynamics. To facilitate this, it would help if there was a monotonic identifier that increased for each commit in-between releases (VERSION=2015e+20150701a perhaps, corresponding to 9ebb8da281487886d4110388eb139578c72d1176, the first commit on July 1 (UTC)). I don't know if that is something reasonable to require of Paul. (And, unfortunately, I don't think there's a good git mechanism for it.) But really I think the complaint is one of consistency and reliability. If a vendor could reliably say, "I can expect a tzdata release to follow within 14 days after a change to a rule that takes effect 14-90 days out, within 30 days after a change to a rule that takes effect 90-180 days out, ..." then the vendor can decide in an informed fashion whether to wait for 2015f or just use 2015e+20150701a. Today, it's very hard for a vendor to predict whether they should wait an unbounded time for a release or should move forward outside the release process. Could the rules be made a little more clear (constraining the maintainer's flexibility, unfortunately)? --jhawk@mit.edu John Hawkinson