[gnu.andrew at redhat.com: Re: OpenJDK 8u and Backport Bugs]

Langer, Christoph christoph.langer at sap.com
Tue Dec 15 15:44:57 UTC 2020


Hi Severin,

<snip>

> > I think actually 11-pool is a major issue here since there will be
> > conflicts with Oracle. Especially for backport items that are open
> > for a long time as once can never know if and when Oracle does
> > backports and whether their engineer will also check JBS at the time
> > of pushing. So, if we manually create the backport items, we should
> > then set the intended target version explicitly. In fact, this seems
> > to be what Oracle does as well. When they are working on a backport,
> > they also sometimes create backport items with a certain target
> > version. This would make life easier for the maintainers as well as
> > they will only have to check whether the version is set correctly.
> 
> OK. So is the concern that by creating explicit backport bugs, setting
> Fix Version to "11-pool" makes it indistinguishable from a bug created
> by Oracle for their work? Setting the fix version to something like
> 11.0.11 (current jdk11u-dev) seems fine to me if that alleviates the
> concern.
> 
> My understanding was that 11-pool bugs would be OpenJDK 11 bugs.
> Perhaps that's not the case.
> 

As far as I know, 11-pool works for both, Oracle and OpenJDK 11 update releases. So if somebody pushes a change to either openjdk 11u/11u-dev or any of Oracle's 11 branches, hgupdate goes and resolves open 11-pool backport as it finds them. (If none of the explicit fix version is present)

> > > > As for the issue of copying all the labels to backport bugs,
> > > > especially those fix request/approval labels that will flood the
> > > > open/unpushed backport lists, that is a known issue. The Skara
> > > > tooling has addressed this already ([0], [1]), so for 13u this isn't
> > > > an issue any longer. And for 11u this will be solved once we go to
> > > > Skara (Another reason for not waiting too long until migrating to
> > > > Skara with 11u ��).
> > >
> > > Right. I'm not convinced Skara will be a solution for 8u, though. So
> > > there is that problem.
> 
> Perhaps we shouldn't rule out Skara :) It might well be part of the
> solution. I should keep an open mind about that. Mea culpa.
> 
> > But 8u is only at the end of the chain... If no release higher than 8
> > generates this bug pollution, I think 8 won't suffer.
> 
> I'm not sure how skara would address the bug-distribution/assignment
> issue, though. Do you know of something that would handle it?

When talking of the benefits of Skara I had in mind that it would not unnecessarily copy labels to the backport bugs. But actually it's a good question how in the Skara workflow open backport bugs are handled. I would assume these get resolved in a similar manner like with hgupdater. So when a release uses git/Skara tooling I think manually opened backport items are still the thing to do.

Best regards
Christoph




More information about the jdk8u-dev mailing list