On Tue, Jun 4, 2019 at 6:07 PM Andrew John Hughes <gnu.and...@redhat.com> wrote:
> > I don't think this is the best approach. JDK-8146467 looks like a pretty > clean snapshot of the tests from not long after 8u GA. It doesn't > include any *9Test.java files for a start. It would seem better to start > with backporting this, rather than taking a random snapshot of the tests > now, and hacking out all the later changes. > I understand the virtues of backport hygiene, having done many backports myself, but here we're just going to disagree. I have a changeset for you, and it is a much better test corpus for jdk8u than the JDK-8146467 backport. > Yes, it may be more tedious to then apply the follow-up test changesets > I'm not applying 36 changesets ! > than to just copy files over initially, but using the original > changesets has the advantage that it also may include fixes to the > source code that go with the test (e.g. JDK-8185830) If you just import > the tests in bulk, you then have to hunt down and analyse each failure, > eventually ending up importing the source code changes from many of > these changesets anyway. > When I'm doing archaeology I look at the much more fine-grained changes in CVS, not hg! > We also then have the administrative benefit of being able to query the > repository as to whether a fix is present or not, by searching for its > bug ID. > When you backport an actual fix later, you will backport the change to src/ as usual and remove one of the DISABLED_JDK8_ prefixes. (Also, the actual jdk8 fix is already in CVS!)
