On 05/06/2019 02:35, Martin Buchholz wrote:
> 
> 
> On Tue, Jun 4, 2019 at 6:07 PM Andrew John Hughes <gnu.and...@redhat.com
> <mailto: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!)

Are you planning to also submit the subsequent changes required here?

My reticence here is over long-term maintainability. If you're planning
to maintain these tests in 8u, then I have no real problem with you
doing it in the way that seems best to you, even if it seems odd from my
perspective.

However, if you just plan to submit this patch and leave the rest for
someone else to sort out, it's a different story.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew

Reply via email to