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

[Hohensee, Paul]

I should have written, "The assignee for an automatically generated backport issue is the original patch author, not the person doing the backport." See, e.g., https://bugs.openjdk.java.net/browse/JDK-8256904, which is the 8u backport issue for https://bugs.openjdk.java.net/browse/JDK-8255603. The backport issue's assignee is clanger, not the person who did the backport push, who was phh. Manually created backports can of course be assigned to anyone, but assigning them to anyone other the original patch author is a change from current practice.

Thanks,
Paul

-----Original Message-----
From: Severin Gehwolf <sgehwolf at redhat.com>
Date: Thursday, December 17, 2020 at 6:46 AM
To: "Hohensee, Paul" <hohensee at amazon.com>, David Holmes <david.holmes at oracle.com>, "Langer, Christoph" <christoph.langer at sap.com>, Andrew Hughes <gnu.andrew at redhat.com>, "jdk-updates-dev at openjdk.java.net" <jdk-updates-dev at openjdk.java.net>
Cc: jdk8u-dev <jdk8u-dev at openjdk.java.net>
Subject: RE: [gnu.andrew at redhat.com: Re: OpenJDK 8u and Backport Bugs]

On Thu, 2020-12-17 at 14:27 +0000, Hohensee, Paul wrote:
> The assignee for a backport is the original patch author, not the
> person doing the backport.

That doesn't sound right. Clicking on More => Create Backport it asks
for a version, enter e.g. openjdk8u292, and an assignee (OpenJDK
username of that). It defaults to the user who worked the master bug.
Could it be that you mean the reporter?

See here for example:
https://bugs.openjdk.java.net/browse/JDK-8258597

Has myself as assignee since I've set it so.

What am I missing?

Thanks,
Severin

> Thanks,
> Paul
>
> -----Original Message-----
> From: David Holmes <david.holmes at oracle.com>
> Organization: Oracle Corporation
> Date: Wednesday, December 16, 2020 at 11:46 PM
> To: "Hohensee, Paul" <hohensee at amazon.com>, "Langer, Christoph" <
> christoph.langer at sap.com>, Severin Gehwolf <sgehwolf at redhat.com>,
> Andrew Hughes <gnu.andrew at redhat.com>, "
> jdk-updates-dev at openjdk.java.net" <jdk-updates-dev at openjdk.java.net>
> Cc: jdk8u-dev <jdk8u-dev at openjdk.java.net>
> Subject: RE: [gnu.andrew at redhat.com: Re: OpenJDK 8u and Backport
> Bugs]
>
> Sorry to butt in but ...
>
> On 17/12/2020 4:43 am, Hohensee, Paul wrote:
> > I really like two things about the current setup, which are (1) all
> > backport info and process is centralized in the original JBS issue,
> > and (2) hgupdater creates the backport issues for me when I push.
> > These mean I only have to look in a single place for backport and
> > other info, and I don't have to spend time creating and maintaining
> > backport issues.
> >
> > With respect to hgupdater getting things wrong, perhaps we could
> > prevail upon Oracle to have hgupdater accept "openjdk<n>-pool".
> >
> > Automatically tracking who's working on what is hard. Maybe I'm
> > missing something, but I don't see a difference between tagging the
> > original issue with, say, "jdk8u-andrew" to indicate that Andrew
> > Hughes is working on it, and manually creating a backport issue.
> > The latter is assigned to the original patch author, and its
> > creator isn't necessarily the one who's working on it, so it will
> > also have to be tagged. I.e., I expect to have to rely on backport
> > issue tags too, so might as well rely on original issue tags.
> >
> > I'm happy to add a "jdk<n>u-<openjdk-name>" tag to an issue when I
> > start work on it. Would that (in addition to the current comment
> > requirements) be enough for tracking purposes?
>
> These "tags" (aka labels) create JBS pollution and email storms IMO.
> I
> don't want to see even more labels being applied to primary issues,
> when
> the label only relates to a specific backport - a backport issue is
> the
> place for that. And in the case of assignee we have a field for that
> so
> don't need a label/tag.
>
> Thanks,
> David
>
> > Thanks,
> > Paul
> >
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> on
> > behalf of "Langer, Christoph" <christoph.langer at sap.com>
> > Date: Tuesday, December 15, 2020 at 7:46 AM
> > To: Severin Gehwolf <sgehwolf at redhat.com>, Andrew Hughes <
> > gnu.andrew at redhat.com>, "jdk-updates-dev at openjdk.java.net" <
> > jdk-updates-dev at openjdk.java.net>
> > Cc: jdk8u-dev <jdk8u-dev at openjdk.java.net>
> > Subject: RE: [gnu.andrew at redhat.com: Re: OpenJDK 8u and Backport
> > Bugs]
> >
> > 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
> >
> >
> >
>