[8u] Request for enhancement backport approval for CR 8207258- Distrust TLS server certificates anchored by Symantec Root CAs

[Andrew Hughes]

On Tue, 26 Feb 2019 at 18:12, Aleksey Shipilev <shade at redhat.com> wrote:
>
> On 2/26/19 7:04 PM, Liu, Xin wrote:
> > When I backport , I always wonder if I shall keep backport patch as intact as possible or piggyback tide-up code?
>
> Keep it intact as much as possible.
>
> Cleanups can and should follow up as the patch in dev, and then trickle down as backports, if needed.
>
> -Aleksey
>
>

For backports, apply the patch as is. If you find it depends on
changes in earlier fixes, backport those
first. Unless they are trivial, this should be in their own
changesets. Either way, make sure to include
the bug IDs of all changes backported for tracking purposes. Some of
the more annoying cases I've
found when backporting are where you are trying to apply a fix which
doesn't appear to be there, and it
fails, only to find that this is because the changes are there, but
under the auspices of a completely
different bug.

In short, hg log -k <bug ID> should work for every backported bug.

As to jcheck, it hooks into your Mercurial setup and runs during
commit. You can use this to catch
issues at the stage, rather than when you push and the server runs
jcheck, rejecting your push.

https://openjdk.java.net/projects/code-tools/jcheck/
-- 
Andrew :)

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

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222