RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v5]

Guoxiong Li gli at openjdk.java.net
Tue Apr 12 12:43:06 UTC 2022

On Tue, 12 Apr 2022 04:12:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

> A JEP is not like a CSR-request. It is extremely rare to create an issue and raise a PR and have someone then say "this really needs a JEP".

@dholmes-ora The current design[4] and this patch have the following advantages or features at least:

**1. Prevent a JEP implemetation PR from accidentally integrating before the JEP has been targeted**

As Jon stated in the SKARA-1096[5]: 
> It would be convenient to mark a PR as dependent on a JEP being targeted. This would help prevent accidental premature integration

This situation has already occured in the past[6-9]. So it is necessary and important to prevent it.

**2. Mark a PR as a JEP implemetation**

The `jep` label can be added to the PR, so the developers can use `is:open is:pr label:jep` in the github to search all the JEPs which are under review. It is nice because we didn't have a right way to search them in the past.

**3. Show the clear JEP Progress in the PR**

This patch adds a checkbox item `Change requires a JEP request to be targeted` in the `Progresses` of the PR body. It shows the clear JEP Progress to the PR author. And the JEP progress can be changed automatically by the bot according to the JEP issue status, which is very convenient.

**4. Provide a JEP link**

This patch provides a JEP issue link in the `Issues` of the PR body. It is also convenient to the developers who want to jump to the JEP issue from the PR.

After this patch integrating, what the PR author need to do is only typing the command `/jep <jep-id>`. Then SKARA can help complete all such good features.


> there was not enough previous discussion at the JDK level to actually conclude anything about the need for this and how it should work.

I posted the first design to the skara-dev mailing list at Dec, 2021[1]. After 3-4 months, I only recieved 2 comments, and one is yours[2]. The skara-dev mailing list has at least dozens of  (if not hundreds or thousands of) subscribers, including all the SKARA reviewers and you @dholmes-ora. Are all of you so busy at these months that you can't give some concrete suggessions or can't give the right mailing list to discuss it?

As you said in the email[2], `I'll have to make enquiries.`:

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

Does you need several months to find a right mailing list? Maybe it is only because all of you are lazy or are not instereting in this issue.

At Mar. 2022, I provided another design[4] and had still waited for your ideas and suggestions. One month passed, no one gave a suggestion or expressed the objection. You have to know that most of the SKARA subscribers are the experienced OpenJDK developers who are both instereted in JDK and SKARA. Such developers can't or don't want to give any suggestion or point the right mailing list. Can the developers from other mailing list can give the actually good suggestions?

If you still think that it need to be discussed. I can post the design detail to the jdk-dev or other mailing lists to re-start the discussion. But I don't think it is necessary personally.


> I think this is totally unwarranted

@dholmes-ora Actually, I am so sad when I read this comment. Because it seems that you have not read the issue[5] and the design[4] (or not read carefully/patiently) before opposing to the whole design. Please read the first advantage mentioned above again, this feature is necessary and important so that @jonathan-gibbons reported the issue[5] and so that we take so much time to discuss and complete the design and patch.


Anyway, It @dholmes-ora you think we need to continue to discuss the design, I am happy to do that. Because I don't want to integrate a patch that all of you don't like. But can @dholmes-ora you provide some real suggesions at the following discussion and provide the reason when stating your opposition, which can let the design and patch better, at the next time?

[1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-December/005481.html
[2] https://mail.openjdk.java.net/pipermail/skara-dev/2021-December/005482.html
[3] https://mail.openjdk.java.net/pipermail/skara-dev/2021-December/005490.html
[4] https://mail.openjdk.java.net/pipermail/skara-dev/2022-March/005770.html
[5] https://bugs.openjdk.java.net/browse/SKARA-1096
[6] https://github.com/openjdk/jdk/pull/290
[7] https://github.com/openjdk/jdk/pull/291
[8] https://github.com/openjdk/jdk/pull/740
[9] https://github.com/openjdk/jdk/pull/769


PR: https://git.openjdk.java.net/skara/pull/1297

More information about the skara-dev mailing list