Managing issues related to the community backports repository

[zakkak]

Hi all,

I would like to propose the following workflow for handling issues related to the community backports repository (and future ones).

1. Create a new issue template for issues related to community builds based on the community backports repositories. The template should ask the user to specify which exact build of the community sources they are using as well as the version. The users should also be prompted to provide a detailed explanation of the issue and a reproducer.
2. Create a new issue template for creating backport requests. The template should ask the user to specify which PR or commit they would like to see backported to which community backports repository.
3. Create new labels to make it easier to track issues related to the community-backports repositories and automatically apply them in the templates mentioned above if possible. Some ideas:
   • Introduce backport-21 backport for all backport requests targeting https://github.com/graalvm/graalvm-community-jdk21u and PRs already backported to https://github.com/graalvm/graalvm-community-jdk21u
   • Introduce community-21 for issues related to community builds based on the community backports repositories.

What do you think?

cc @alina-yur @fniephaus @simonis @jerboaa @Karm

Update: Updated to reflect suggestion from #9590 (reply in thread)

[jerboaa]

@zakkak How about just using one label for both? community-21-backport. Otherwise sounds great to me!

[zakkak]

That would be acceptable as well I guess, but it makes it harder to distinguish reported issues from backport requests. Perhaps we could introduce community-21 for both, and a generic backport label to mark backports (and backport requests) in general (even ones on the https://github.com/oracle/graal repository, e.g. https://github.com/oracle/graal/pulls?q=is%3Apr+base%3Arelease%2Fgraal-vm%2F24.1+)

[jerboaa]

+1 to community-21 and backport labels.

[zakkak]

Requested in #9825

[simonis]

Is my understanding correct that we will create an issue for each change that we downport? If yes, I think that would be great.

The template for such issues should contain a link to the original commit/PR/issue (and not a version that was already downported or integrated into other versions/branches). From my understanding, there should always be an original commit, but curretnly in the GraalVM project there's not always a (public) PR for a commit and also not always a (public) issue for a commit or PR. Is that correct? In any case, the issue we create for a backport should capture as much of the available information as possible.

Is it possible to retroactively label the original commit/PR/issue with our labels? That would be nice. The background is as follows: if a user runs into a problem and finds an original commit/PR/issue which describes his problem, how can he find out if the commit has already been integrated into e.g. our community backports repository and if yes, in which release it was integrated? In OpenJDK this is all pretty trivial - once you find a JBS issue, you can go to the corresponding commit and PR and you can easily find all the downports together with the exact updated release versions into which they were integrated. It would be great if we could get as much of this functionality as possible in GraalVM and make it work as much as possible automatically and by default. Because if we have to rely on too much manual interaction and good will, we will be lost :(

[zakkak]

Is my understanding correct that we will create an issue for each change that we downport? If yes, I think that would be great.

Can you please provide some motivation for that? Since we can (and should IMHO) include all the available info in the PR description (and use the same labels and filtering we can use with issues) what would be the benefit of having both a backport/downport issue and a PR?

The only case I imagine having a backport/downport issue created is when someone finds out that some fix needs to be backported but are not able to do the backport themselves, so they create the issue as a "request" or "todo".

The template for such issues should contain a link to the original commit/PR/issue (and not a version that was already downported or integrated into other versions/branches).

+1

From my understanding, there should always be an original commit, but curretnly in the GraalVM project there's not always a (public) PR for a commit

AFAIK this is no longer the case. All changes should go through a PR nowadays, but there are still past commits that are indeed not accompanied by a PR.

and also not always a (public) issue for a commit or PR. Is that correct?

Unfortunately that's true. Most PRs/commits are not accompanied by a (public) issue and many times they even lack a proper description.

In any case, the issue we create for a backport should capture as much of the available information as possible.

+1

Is it possible to retroactively label the original commit/PR/issue with our labels? That would be nice.

For PR/issue we technically can, commits unfortunately can't be labeled AFAIK.

The background is as follows: if a user runs into a problem and finds an original commit/PR/issue which describes his problem, how can he find out if the commit has already been integrated into e.g. our community backports repository and if yes, in which release it was integrated? In OpenJDK this is all pretty trivial - once you find a JBS issue, you can go to the corresponding commit and PR and you can easily find all the downports together with the exact updated release versions into which they were integrated.

+1 that's exactly the motivation behind the proposed labels and the structured templates.

It would be great if we could get as much of this functionality as possible in GraalVM and make it work as much as possible automatically and by default. Because if we have to rely on too much manual interaction and good will, we will be lost :(

That would be nice, but my intuition is that it will need quite the effort both to implement and get it approved to run on https://github.com/oracle/graal

[simonis]

Is it intentional that we don't have issues and discussions enabled for the https://github.com/graalvm/graalvm-community-jdk21u repository and if yes, why?

Id' also like to suggest to change the "About" description of https://github.com/graalvm/graalvm-community-jdk21u to include the GraalVM version:

Maintenance repository for GraalVM 23.1.x Community for JDK 21. To report issues or request backports, go to https://github.com/oracle/graal.

As said before, it's not clear why we have to redirect people to the https://github.com/oracle/graal repository for issues and backport requests?

[zakkak]

Is it intentional that we don't have issues and discussions enabled for the https://github.com/graalvm/graalvm-community-jdk21u repository and if yes, why?

Yes.

As said before, it's not clear why we have to redirect people to the https://github.com/oracle/graal repository for issues and backport requests?

The reasoning behind this was to have a central place for issue tracking where it will be easier to lookup issues, link between them, see their state etc.

Other benefits I see with this approach are:

1. We avoid confusing users with what/when they are supposed to use.
2. We keep everything in the "upstream" repository. Some issues seen in JDK 21 might actually affect master as well.
3. We increase the chances of someone reporting an issue to see whether this has been reported again in the past (for a different version) and if it's an actual issue, whether it has been already fixed in another version etc.

What do you think is the main drawback of this approach and what would we gain by moving the issue tracking under https://github.com/graalvm/graalvm-community-jdk21u ?

Id' also like to suggest to change the "About" description of https://github.com/graalvm/graalvm-community-jdk21u to include the GraalVM version:
Maintenance repository for GraalVM 23.1.x Community for JDK 21. To report issues or request backports, go to https://github.com/oracle/graal.

+1