On Wed, 18 Sep 2013, Andy Heninger wrote:
In an ideal world, from my perspective, changes that affect the present or near future time would be kept separate from other changes, and have a fast-track release process. And perhaps substantial cleanup and historical data updates would be kept away from the busy times in March-April, and September-October, when all too many countries seem to think it's OK to announce that they changed their clocks last weekend.
From my point of view, as the person who handles tzdata updates for NetBSD, I would prefer to have no controversial changes in any tzdata update ever. I suggest that a possible way of achieving the goal of no controversial changes, would be to have at least two branches in the upstream repository. I'll name the branches "proposed" and "approved" for the sake of this message. Changes could be committed first to the "proposed" branch, then merged to the "approved" branch after discussion. Releases would be made from the "approved" branch. I also like the idea of avoiding potentially disruptive changes during the busy times of March-April and September-October. If we had already been using this scheme over the past month or so, then the Fiji and Liechtenstein changes would be in the "approved" branch, and would be released soon, while the changes that some people are unhappy about would be in the "proposed" branch, and would be discussed further, and possibly reverted or modified. Of course, any OS vendor can do its own separation of changes into different categories, and merge only the uncontroversial tzdata changes into OS release branches. The question has never come up before, for NetBSD, because we have not been aware of such controversial changes before. --apb (Alan Barrett)