[Investigation] The design for SKARA-1096 about JEP check

[David Holmes]

Hi,

On 2/12/2021 8:54 pm, Guoxiong Li wrote:
> Hi all,
> 
> I am going to start working on SKARA-1096 [1] about the JEP check which is
> like the CSR check.
> Firstly, I would like to discuss the concrete design with you and
> receive your suggestions.
> 
> I propose the following draft design:
> 
> *1. Add issue link types `jep of` and `jep for` in the JBS.*
> 
> This is similar to the `csr of` and `csr for`.

I don't think that is a decision to be made just in skara-dev. I'm not 
certain where would be the best place to discuss it ... we don't have a 
general infrastructure mailing list to discuss JBS. I'll have to make 
enquiries.

Cheers,
David

> Currently, the JEP issue and its implementation issue has at least 3
> relationship:
> (1) The implementation issue is a `relates to` link of the JEP issue. Such
> as JDK-8264130 [2]
> (2) The implementation issue is a `Sub-tasks` link of the JEP issue. Such
> as JDK-8276797 [3]
> (3) The implementation issue is a `is blocked by` link of the JEP issue.
> Such as JDK-8269306 [4]
> They should be unified when we use the skara bot to run the automatic job.
> Only the ongoing JEPs, which excludes the finished JEPs,  need to add the
> `jep of` link because the bot don't check the finished JEPs.
> Only when a developer is working on a JEP should he/she add the link by
> himself/herself. So it is not hard to add this link.
> After this SKARA-1096 completed, we can send an email to `
> jdk-dev at openjdk.java.net` to notify all the JEP developers to add such link.
> 
> *2. Add `JEP` label in the corresponding Github repository.*
> 
> The `JEP` label means that the JEP is being reviewed and has not targeted.
> If a repository or project has the `JEP` feature, we need to add the `JEP`
> label to its Github code repository.
> Currently, I only know that the JDK mainline need to add the `JEP` label.
> I need your help to list the projects which need the `JEP` label.
> 
> *3. Add a bot in the skara to automatically check the JEP.*
> 
> When the developer submit a PR in the Github, the bot will check the `jep
> for` link of the main issue of the PR.
> 
> If the bot finds a `jep for` link which has not targeted, it would complete
> the following things:
> (1) Add the `JEP` label to the PR.
> (2) Add a checkbox item, such as `Change requires a JEP to be targeted`, to
> the `Progress` part of the PR body. Similar to SKARA-1254 [5]. Because of
> this, we don't need to add the JEP integration blocker.
> (3) Add the JEP issue link to the `Issue` part of the PR body. Similar to
> SKARA-286 [6]
> 
> If the bot finds that the `jep for` link has been targeted, it would
> complete the following things:
> (1) Remove the `JEP` label of the PR.
> (2) Check the checkbox item which is in the `Progress` part of the PR body.
> Note: the JEP issue which is in the `Issue` part of the PR body won't be
> removed.
> 
> If the bot doesn't find the `jep for` link, it won't do any thing. (no
> `JEP` label, no checkbox item, no JEP issue link)
> 
> *4. Not add the command such as `/jep`.*
> 
> Currently, we have the `/csr` command. Its value is less when the
> SKARA-1071 [7] is integrated.
> We have discussed about removing the `/csr` command when solving SKARA-1071
> [8].
> But finally, we decided to leave it, because the following reason:
> (1) The PR author might not realize that a CSR is needed. So the command
> `/csr needed` can be used by the Reviewer to indicate that a PR needs to
> have a CSR.
> (2) The `/csr unneeded` command can prevent that a PR author with the role
> of Committer withdraw a CSR that a Reviewer had requested and integrate the
> PR without satisfying that requirement.
> 
> Back to the command `/jep`, I think the similar situation has not existed.
> (1) The JEP is firstly created to start the discussion. Then the JEP
> implementation issue and PR is created. So we always know that JEP
> implementation issue needs the JEP issue to be targeted(Approved). So the
> command `/jep needed`, like `/csr needed`, is not really needed.
> (2) The JEP developers are some senior developers who can realize the JEP
> is needed.
> (3) Only the project lead can target(approve) the JEP, so we don't need to
> prevent that the developers integrate the PR without targeting the JEP. So
> the command `jep unneeded`, like `csr unneeded`, is not needed.
> 
> The current design is shown above.
> Any idea and suggestion are appreciated.
> 
> Best Regards,
> -- Guoxiong
> 
> [1] https://bugs.openjdk.java.net/browse/SKARA-1096
> [2] https://bugs.openjdk.java.net/browse/JDK-8264130
> [3] https://bugs.openjdk.java.net/browse/JDK-8276797
> [4] https://bugs.openjdk.java.net/browse/JDK-8269306
> [5] https://bugs.openjdk.java.net/browse/SKARA-1254
> [6] https://bugs.openjdk.java.net/browse/SKARA-286
> [7] https://bugs.openjdk.java.net/browse/SKARA-1071
> [8] https://github.com/openjdk/skara/pull/1245
>