[tz] Commentary-only releases - let's not (was: Re: Please Don't Feed the Trolls (was Kyiv not Kiev))

[Philip Paeps]

On 2022-07-01 10:45:00 (+0800), Stuart Bishop via tz wrote:
> On Wed, 29 Jun 2022 at 17:51, Philip Paeps via tz <tz at iana.org> wrote:
>> On 2022-06-28 20:54:13 (+0800), Martin Burnicki via tz wrote:
>>> even though usually a new version of the DB is only released if some
>>> TZ rule was changed, it should not be too hard to simply release a 
>>> new
>>> version now
>>
>> I strongly disagree with this view.
>>
>> While the effort required from the tz coordinator to tag a release 
>> may
>> be minimal, this is not the case for the many downstream maintainers.
>> Every update presents a risk.  Bear in mind that tzdb updates end up
>> being pushed to hundreds of millions of end-user devices, if not 
>> more.
>>
>> Downstream maintainers are cranky enough as-is, following the churn 
>> in
>> 2021 (which still has not been completely resolved).  If we start
>> tagging tzdb releases without actual tz changes, downstream 
>> maintainers
>> will be even more likely to diverge from the closely tracking tzdb.
>> This is ultimately bad news for end users.
>>
>> For the avoidance of doubt: I completely agree that renaming 
>> Europe/Kiev
>> to Europe/Kyiv was the correct thing to do.  My objection is to 
>> tagging
>> tzdb releases with only commentary changes and no data changes.
>
> Counterpoint, as a downstream maintainer I would appreciate prompt 
> releases
> for popular requests such as the renaming of Europe/Kiev. Fielding 
> requests
> and redirecting them to IANA has already taken more time and mindshare 
> than
> me popping out a new release with updated data. In hindsight I should 
> have
> added an override and made a release months ago.

All downstream maintainers have been in this boat.  But we're a couple 
of dozen people at most.  We have to weigh our efforts fielding email 
against the risk of updating hundreds of millions of end-user devices.  
Every update, no matter how trivial, is risky at that scale.  Releases 
without tz changes would do much more harm than good.

> If anything, infrequent releases are more of a problem for me (of 
> course I
> can't speak for other downstreams). The longer between releases, the 
> more
> likely it is that my release machinery has atrophied, the more 
> accumulated
> bugs need to be fixed, and under higher time pressure as the release 
> is
> more likely to have some time critical change included. While I don't 
> think
> every change prompting a release would be good, I do think an expected
> release cadence of one release every 3-4 months would be an 
> improvement,
> along with the occasional unexpected release containing time critical
> changes.

This is a good suggestion but I don't it's practical.  Time zone changes 
tend to happen in bursts around March and October.  If we scheduled 
releases at the beginning of January, April, July, and October, we'd 
invariably end up doing at least one additional release in April and 
October.  Shifting the scheduled release to the end of the month, we'd 
end up doing at least one additional release earlier in the same months. 
  And more often than not, the January and July releases would be devoid 
of tz changes.

As Tom points out, we actually have a fairly predictable schedule today: 
bursts of releases around the silly seasons in March and October and one 
or two releases at other times.  I'm not too worried about our release 
machinery atrophying.

Unfortunately, the nature of the data we record means we'll always have 
to make releases on short notice.  Considering the end-user impact of 
every release, making releases with tz changes, only when necessary, is 
a better compromise than making releases on a schedule, but without tz 
changes, in addition to releases with tz changes, when necessary.

Philip

-- 
Philip Paeps
Senior Reality Engineer
Alternative Enterprises