----- Original Message ----- > On 21/07/16 16:52, Andrew Hughes wrote: > > As a compromise, I suggest doing a single patch for the main > > patch import (up to changeset 9ee6abf28de9) which corresponds > > to the whole port in the same way the initial AArch64 port was > > done, and gets rid of the problematic changesets. > > > > The remaining changesets, which either have OpenJDK bug IDs or > > could trivially be assigned them, should be imported > > as-is, so they will then be recorded as fixed in OpenJDK 7, rather > > than being lost in a mega patch. > > But if they are bug fixes to a new import then they will never have > been recorded as broken in OpenJDK 7, so why do they need to be > recorded as fixed in OpenJDK 7? > > Andrew. > >
I'm not sure what you mean by "recorded as broken in OpenJDK 7". It would be the same as for other fixes we backport; they are filed as bugs against 9, but backports are often made all the way back to 6. For a bug ID such as the recent 8158260, I can do: $ hg log -R ../jdk9/hotspot -k 8158260 changeset: 11520:5f3687f2143c user: simonis date: Fri Jun 17 11:31:24 2016 +0200 summary: 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of illegal instructions $ hg log -R ../jdk8/hotspot -k 8158260 changeset: 7947:6021c95f5944 user: simonis date: Tue Jun 14 19:48:30 2016 +0200 summary: 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of illegal instructions $ hg log -R ../icedtea7/hotspot -k 8158260 changeset: 6414:601fbf4bf8c1 tag: tip user: simonis date: Wed Jul 20 03:15:59 2016 +0100 summary: 8158260, PR2992, RH1341258: PPC64: unaligned Unsafe.getInt can lead to the generation of illegal instructions I guess you could do that by including all the bug IDs in the mega patch too, but, in general, this idea of mega patches just defeats the whole point of using a version control system altogether. With OpenJDK 6, I still regularly run into changes which come down to bulk imports of tarballs from before we had the Mercurial trees, such as "6755902: Changes for openjdk6 build 03", and it makes it very hard, if not impossible, to know why a particular change was made. When backporting changes, you find differences between e.g. 7 and 8, and you need this kind of data mining, from tools like hg annotate, in order to establish why that change exists and whether or not it needs to be kept. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222
