[jdk17u] RFR: 8352097: (tz) zone.tab update missed in 2025a backport

[Andrew John Hughes]

On Thu, 20 Mar 2025 01:16:28 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> As with [21u](https://github.com/openjdk/jdk21u/pull/460), the [17u backport](https://git.openjdk.org/jdk17u-dev/commit/06ea6d5c17899df8fd83d0b14983c7c1e88d9cde) of the tzdata 2025a update missed an update to zone.tab, as this was not present in the [25u commit](https://git.openjdk.org/jdk/commit/caa3c78f7837b1f561740184bd8f9cb671c467eb) on which it was originally based, due to its removal in [JDK-8166983](https://bugs.openjdk.org/browse/JDK-8166983). The change was in [the 24u commit](https://git.openjdk.org/jdk24u/commit/81252ef76899ad95197550a11c2786ccf3cf0cd2) which was applied later than the 21u one.
> 
> We should add this missing change to the existing 2025a update in 17.0.15 and consider backporting JDK-8166983 for 17.0.16 (now proposed for [24u](https://github.com/openjdk/jdk24u/pull/150)).
> 
> Backport from 21u is clean. Tests pass:
> ~~~
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/jdk/java/text/Format                     111   111     0     0   
>    jtreg:test/jdk/java/util/TimeZone                    25    25     0     0   
>    jtreg:test/jdk/sun/util/calendar                      5     5     0     0   
>    jtreg:test/jdk/sun/util/resources                    22    22     0     0   
>    jtreg:test/jdk/java/time                            186   186     0     0   
> ==============================
> TEST SUCCESS
> ~~~

> > > This is identical to the backport to 21. The edited file lives in a different directory, therefore this is not a clean backport. I second that this goes to jdk17u.
> > 
> > 
> > `git cherry-pick` handled the file movement automatically so I would regard this as clean, much as I would regard automated path shuffling from 11u to 8u as clean. No manual intervention was required and there are no differences in the body of the `diff`.
> 
> Thanks for giving this additional information. The fact that you could created this automatically reduces the chance for error. But this context is needed to make the information useful for a reviewer. Also, as approver, I usually take a different look if I know no reviewer was involved. And as backporter to a later release, I would like information about the previous backports. In both cases, and similar with the 24u backport of the timezone change, it is helpful if a change like this is not labeled as "clean".

It's not labelled 'clean' :) I have issues with that label myself. I don't agree with a 'clean' determination being sufficient reason to not review a patch. It's why I made a point of reviewing your LCMS patches. A patch can easily be 'clean' by simply adding a completely new file that then breaks the build. It's reassuring to hear that you are wary of such changes as well.

I've used the term 'clean' long before we were working on GitHub to mean what I wrote above, and only what I wrote above; that it applied without manual intervention. I don't intend it to mean the patch does not need review and I'll try to be more explicit on this in future.

I hadn't actually realised that this one had auto-path-shuffled because it did so completely silently and - most importantly - the build & testing went fine. Now I think about it, I  have seen this happen with other recent tzdata updates too.

> Btw, would skara handle the file path differnces? I just did the backport of JDK-8303770, which has the same path issue but the test needs to be resolved. I know there are backports that succeed with the /backport command and are not recognized clean, and vice versa.

I haven't tried `/backport` with this one, but I am aware that it has some fuzzy logic that can e.g. handle copyright header differences.

-------------

PR Comment: https://git.openjdk.org/jdk17u/pull/405#issuecomment-2742003803