Initial mailing list mapping rules for the jdk repository

[rwestberg]

Hi all,

This is an initial version of the mailing list mapping rules that will be used after the main jdk repository transitions to Git and starts accepting pull requests. This is not the final location of this list (currently it is part of a bot configuration file, but could conceivably also reside in the jdk repository itself) - but in order to improve it I am going to ask for help from knowledgeable JDK contributors to refine the rules for areas that they are interested in. Using the Skara repository to coordinate such updates seems reasonable.

This initial version has been created by looking at reviews for existing commits and matching them with a review on a mailing list. That list has then been adjusted manually by applying the generated rules to existing commits, and checking if they actually match the lists that were used for reviewing them.

Finally I've also applied the rules found at https://openjdk.java.net/groups/2d/2dawtfiles.html (thanks @prrace!) and I suspect that similar lists exists for many more parts of the JDK, but perhaps not written down. So this is the expert knowledge I am looking for!

When the initial version has been integrated, I'll send out a separate email with more details on how it can be used and tested.

Best regards,
Robin

---

Progress

• Change must not contain extraneous whitespace
• Change must be properly reviewed

Reviewers

• Erik Helin (ehelin - Reviewer)

Download

$ git fetch https://git.openjdk.java.net/skara pull/738/head:pull/738
$ git checkout pull/738

[bridgekeeper]

👋 Welcome back rwestberg! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request.

[edvbld]

I can't comment on the details of the rules, but looks good to me in general 👍

[openjdk]

@rwestberg This change now passes all automated pre-integration checks. When the change also fulfills all project specific requirements, type /integrate in a new comment to proceed. After integration, the commit message will be:

Initial mailing list mapping rules for the jdk repository

Reviewed-by: ehelin

• If you would like to add a summary, use the /summary command.
• To credit additional contributors, use the /contributor command.
• To add additional solved issues, use the /issue command.

Since the source branch of this PR was last updated there have been 7 commits pushed to the master branch:

• 2851535: 466: Exception during sponsored integration
• 90bb640: bots: add checkout bot
• 089215d: Store target hash before potentially fetching the ref
• 5459a0b: webrev: follow files for commits.json
• 05d9d69: vcs: add method ReadOnlyRepository.follow
• d6a5ab4: hg: use --template instead of ext.py for metadata
• 87141a3: actions: Use explicit versions of OS environments

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid automatic rebasing, please merge master into your branch, and then specify the current head hash when integrating, like this: /integrate 2851535eb91954e9f7bb220a1d0608b392fcc637.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[mlbridge]

Webrevs

• 00: Full (f6c4e94)

[kevinrushforth]

What rules will be used for new files that don't match any of the existing patterns? For example, if a new package is added to java.desktop, where will the RFR go?

Does the logic support adding a later more general pattern that will only be used if an earlier more specific pattern isn't matched? In that case, it would be possible to add a src/java.desktop (for example) that is sent to one of the client aliases (whichever Phil thinks is the best default) as a "catch all" for anything that is missed by the specific set of patterns.

[rwestberg]

The rules should ideally be written in a form that will match unknown files, for example like this java.desktop one for awt-dev:

"src/java.desktop/share/classes/sun/awt/(?!font|sunhints|color/|font/|geom/|im/|image/|print/)",

It's written to be complementary to other rules (in 2d-dev and i18n-dev in this case) so that it matches anything not followed by these specific folder names.

In the case that nothing matches, it will currently log an error that the Skara admins can investigate and hopefully improve the list. But in the future it is probably a good idea to add a specific category of rules that are used if none of these specific ones matches. But I'm hoping the first approach will help improve the quality of the primary filters to begin with.

[rwestberg]

/integrate

[openjdk]

@rwestberg The following commits have been pushed to master since your change was applied:

• 2851535: 466: Exception during sponsored integration
• 90bb640: bots: add checkout bot
• 089215d: Store target hash before potentially fetching the ref
• 5459a0b: webrev: follow files for commits.json
• 05d9d69: vcs: add method ReadOnlyRepository.follow
• d6a5ab4: hg: use --template instead of ext.py for metadata
• 87141a3: actions: Use explicit versions of OS environments

Your commit was automatically rebased without conflicts.

Pushed as commit 0d9698b.