Andy Heninger wrote:
The Fedora approach of patching the data but continuing to identify it as something that it is not can lead to real confusion.
Sure, but Fedora doesn't identify it as plain 2013c: Fedora 19, for example, uses what it calls version 2013c-2. Debian is similar; Debian 7.1 uses what it calls 2013c-0wheezy1. OpenSUSE 12.3 uses its own 2013d-1.2. And so forth. This common approach works and scales reasonably well to a large number of distributions. If we changed the tz maintenance approach, and identified some patches to be higher priority and shipped them out in a separate tarball, that would complicate maintenance. Almost inevitably we'd need one or more forks in the upstream tz release: at least a "stable" branch versus an "even more stable" branch, and possibly more branches besides, depending on which distributions want which changes. Each new branch would need a separate release schedule and separate testing, and maintaining all the branches would be more hassle both for upstream and downstream maintainers. For a sufficiently-complicated software system this kind of complexity might be worthwhile, but the tz code and data are reasonably simple, and such complexity hasn't been needed in the past, even for tz updates that were fairly hefty. I'll admit to having a bit of a bias here, as much of the maintenance burden would fall on me while the benefit would accrue to you; but even so the overall benefits of changing the tz maintenance procedure don't clearly outweigh the costs.