[tz] Moving more zones to 'backzone'

[Paul Eggert]

On 8/17/22 04:02, Robert Elz wrote:

> 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.

Even when context matches, I've seen 'patch' apply changes in the wrong 
place due to the file having two places with similar context. Admittedly 
this happens only when we're doing the equivalent of merging branches, 
but it can happen.

More important, sending diffs via email is notoriously dicey due to 
email software messing with white space. One can get around this problem 
by attaching diffs rather than sending them inline, but this is more 
hassle for the reader.

Still more important, diff output doesn't address the problem of the 
commit message, something I mentioned in my earlier email. And now that 
I think about it, diff output also lacks author and timestamp info.

Although I could work around these problems by hand, that'd be 
make-work, which is why I'm asking for 'git format-patch' form. This 
form was designed after a lot of experience with the abovementioned 
problems, and it's a better design in pretty much every respect.

Although you don't want to use Git, I hope this explains why I want git 
format-patch form. Perhaps you can write some code to generate the right 
form without using Git, or find someone else to volunteer to use Git to 
generate the desired form.

This issue is not unique to Git, as I often deal with other projects 
with preferences about patch format. Most prefer Git which is not 
surprising as Git is #1 in this space now. A few, though, use 
Subversion, or Mercurial, CVS (!), or even "diff -c" (!!) and I send 
patches in the form they prefer.


> 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.

Those issues didn't affect in-scope data, and so they are important only 
to those who think that 'backzone' is important. Such people can, if 
they like, step up to maintain 'backzone' and deal with the inevitable 
make-work and political flames. (I should warn, though, that Bradley 
White merely reported the tip of the iceberg of backzone's problems.)

Again, I don't advise you or anybody else to take up the task of 
maintaining 'backzone' - your limited time is better spent elsewhere. 
But if you want to do it despite my advice, please feel free.


> 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.

There are some limits to commit messages. We shouldn't install anything 
that infringes copyright, defames, contains pornography, etc. But let's 
not worry about ordinary mistakes in commit messages. Lots of TZDB's 
commit messages already have uncorrected mistakes. That's OK.


> You'd not be saving any work by getting a git format patch from me,
> probably actually adding steps.

For this sort of thing all I want to do is to either (1) say "The patch 
isn't right; please fix and resubmit" or (2) install the patch as-is. 
The idea is for us to get used to the process so that (1) is rare. If 
that can't be arranged then let's not bother.


> unless git allows the log entries to be revised

It doesn't. That is, Git doesn't let you change any part of any commit. 
At most one can create a different commit (with a different commit ID) 
and remove the old commit, but I have never done that to TZDB despite 
many mistakes in commit messages. I would do such a thing only if a 
copyright infringement etc. somehow sneaked into the repository, which I 
hope never happens.


>    | >    | 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

Although I interpreted that as a request to add Europe/Pristina, that's 
no big deal, as whoever's maintaining 'backzone' can interpret such 
requests. I have also gotten private emails on the topic, emails that 
I'd rather not redistribute; if people step up to maintain 'backzone' we 
can ask requesters to correspond with the 'backzone' maintainers about 
out-of-scope data like that.