[tz] Release policy [WAS: Error Correction Request: Europe/Kiev to Europe/Kyiv]

[Tim Parenti]

On Tue, 5 Jul 2022 at 12:28, Fred Gleason via tz <tz at iana.org> wrote:

> Is there policy somewhere that states how long before the effective date
> of the change a release should be cut?
>

There is not.  And since our effective floor is two releases per year (or
one per "silly season", as it were) there's no strong reason to impose
one.  I mentioned some specific examples in
https://mm.icann.org/pipermail/tz/2022-July/031574.html

As such, one could make the case that we operate in minimal chunks of about
6 months each.  The benefit to a country for announcing a change with more
than ~6 months' notice is the reasonable assurance that, even without any
other urgency, the change will hit a release no later than the end of the
next "silly season" after the announcement, which will tend to be between 1
and 6 months before it takes effect depending on the exact timing.
Similarly, the benefit for announcing more than ~12 months out is a release
lead time of 7 to 12 months, and upward in 6-month increments.  (Now,
depending on the vagaries of any given "silly season" and the exact dates
things arrive and go into effect, whatever might make it into any given
release one year might miss a similar release in another, but the general
principle still holds.)  And the benefit for project and downstream
maintainers is that none of us have to do anything special or undertake any
urgent work in order to achieve those lead times.

Of course, the corollary which should be obvious to regular readers of this
list is that if you announce changes with less than ~6 months' notice,
you're guaranteed nothing.  ;)  As that describes most of our changes —
typically made during the "silly seasons" themselves — they can be
informally classified on a sliding scale of urgency depending on when they
arrive relative to their effect.  Those a bit further out might prompt us
to wait a bit to see if we can batch it with something else that comes in
later, saving us all some maintenance burden, while those closer to their
effective dates will tend to prompt that a release be cut more urgently
(within reason).

In practice, readers will note that we tend to keep good tabs on when the
data in the most recent release is about to "expire" and accelerate or
decelerate accordingly.  Adding any arbitrary target such as "release
changes 30 days ahead of effect" wouldn't help, as that would create
needless artificial urgency and resultant churn on any changes that would
arrive at 31 days out, while doing nothing to help those that would arrive
at 29 days.

--
Tim Parenti
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/tz/attachments/20220705/0cdc8730/attachment.html>