[tz] draft of change summary for next tz release
Paul Eggert
eggert at cs.ucla.edu
Thu Sep 19 00:18:16 UTC 2013
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.
More information about the tz
mailing list