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

[Guoxiong Li]

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