[tz] Moving more zones to 'backzone'

[Robert Elz]

    Date:        Mon, 15 Aug 2022 16:21:52 -0700
    From:        Paul Eggert <eggert at cs.ucla.edu>
    Message-ID:  <47967be4-875f-368b-54a0-580a5d96703d at cs.ucla.edu>

  | Sure, and 'patch' often goofs up - which is partly my fault as I am one 
  | of the three maintainers for 'patch'.

I don't think I have ever seen patch, when given any of the forms of
context diff, "goof up" - unless you include not being able to apply
the patch (because the context of the source has changed since the
patch was created) as such a goof - I don't.

It does odd things sometimes in non-context forms, when it is relying
on just line numbers to identify where the patch goes.  That only works
(can only be expected to work) when the base file has not altered at all.

  | Plus, 'patch' is just part of the job. Often the commit message is just 
  | as important as the actual change. 'git format-patch' and 'git am' 
  | handle this nicely; 'patch' does not.

Yes, but it was that which I was referring to here:

  | > in non-compiled data (data not subject
  | > to automated checking) I tend to make all kinds of typos, which would
  | > need correcting, and second, because the kind of comments I would supply
  | > are unlikely to be the kind you'd be willing to commit.

Not to the data that would be being put into the file, which would not
be ...

  | It's OK if typos are limited to 'backzone' as it has unimportant data.

that one, as I will only do this if the data goes back in the files from
where it has been removed (those are what I work with), and in any case,
none of the data is unimportant, whatever file it happens to be placed in.

Separating out the data, and just having the mindset that some of it is
unimportant, is what leads to problems like the issues that Bradley White
identified with 2022b/2022c.

But back to the point, it is the commit message that would likely have lots
of typos (look at some of my commits to NetBSD - the log messages are full
of stuff like that, unfortunately), and most likely also have comments that
you are unlikely to want to have stored in the git history of the data.
You'd not be saving any work by getting a git format patch from me,
probably actually adding steps.

  | Plus, you can always fix any typos later, whenever you get around to it. 
  | As for comment format let's see what sorts of comments you write: if 
  | others who care about 'backzone' don't care about the comments then I'm 
  | not likely to care either.

So, that's not relevant - unless git allows the log entries to be
revised, in which case, that's just one more strike against git.

Obviously the data in the file (whether that be data that zic processes,
or comments) is subject to later revision, that didn't need saying.

  | >    | Europe/Pristina, and this is a win.
  | > I don't recall seeing anyone request one

  | Here's one example:
  | https://mm.icann.org/pipermail/tz/2014-January/020589.html

It is no wonder I did not remember that, but neither that short
thread, nor the one from May 2013, really amount to a request to add
the zone - more a "I wonder if we should be adding ..." type thing.

The earlier discussion seemed to be most concerned about whether
Kosovo is a country or not, which is irrelevant to me (I'm sure it
is important to many people, but I'm not one of them, and it should
never be important here either - fine to add an assigned country
code if it has one, but even if it doesn't, it still has time).

With hindsight, back then would probably have been a good time
to at least create the zone name as a link.   I certainly don't
see any problems doing so would have caused (beyond the normal
extra effort creating any new zone requires.)

kre