[tz] draft of change summary for next tz release

[Alan Barrett]

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)