Tracking dependencies between backport bugs

[Lindenmaier, Goetz]

Hi Jonathan,

I would not consider this a dependency between the bugs. 
There is no semantic connection between the two.
It's just a conflict in the context, right?
Resolving them is trivial. So you should just downport what 
you want to downport. If you plan to do them both, 
do them in the right order.  If you only want to downport 
JDK-8196196 do it, and resolve the files.

If you think about downporting JDK-8078614, you should
consider whether you need the fix in 
src/java.desktop/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java
in 8.  You should not downport such an issue just because of a
conflict in context with a change later in the source.
Having conflicts and resolving them is the very business of 
downporting ��

Best regards,
  Goetz.

> -----Original Message-----
> From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> On Behalf Of Jonathan
> Dowland
> Sent: Wednesday, January 6, 2021 12:25 PM
> To: jdk8u-dev at openjdk.java.net
> Subject: Tracking dependencies between backport bugs
> 
> Happy New Year!
> 
> I'm picking up work on backporting JDK-8196196, which is one of those
> large test-tagging patches. The current WIP backport patch drops about
> half of the original patch. In line with prior discussions, I'm now
> investigating whether the hunks that don't apply in 8u shed light on
> some other patches that should be backported first.
> 
> The first concrete example for this bug is the file
> test/javax/swing/JComboBox/6632953/bug6632953.java, for which the hunk
> does not apply in 8u yet, because JDK-8078614
> ("WindowsClassicLookAndFeel : MetalComboBoxUI.getbaseLine fails with
> IllegalArgumentException") needs to be applied first. I personally think that
> JDK-8078614 looks suitable for backporting to 8u, although it might fail
> on the criteria (it's not an Oracle parity patch I don't think?)
> 
> My question is: (how) should I record this dependency in JBS?
> 
>  * Should I create a Backport bug for JDK-8078614, and then mark that as
>    a blocker against the backport bug for JDK-8196196 (this already
>    exists, it's JDK-8257838).
> 
> Note that I'm not sure that I will work on this dependent bug myself (in
> particular this is a Windows-only bug: although it looks trivial enough
> I can probably test it to satisfaction, in general I can't work on
> Window specific bugs). For now I just want to capture all the
> dependencies of the main backport I'm looking at.
> 
> 
> Best wishes
> 
> --
> ���� Jonathan Dowland <jdowland at redhat.com>
> Senior Software Engineer, OpenJDK, Red Hat