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

[David Holmes]

On 18/12/2020 12:27 am, Hohensee, Paul wrote:
> The assignee for a backport is the original patch author, not the person doing the backport.

That is the default, but it can be changed.

David

> 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
>>
>>
>>
>