Request for assistance: Verify and update mailing list filter rules for jdk/jdk in preparation for Skara transition

Alex Buckley alex.buckley at oracle.com
Thu Aug 27 16:05:47 UTC 2020


How does a contributor know which mailing list should be used for a 
given code change? The answer shouldn't be held in the institutional 
memory of Oracle's Java Platform Group. The answer should be written 
down in a public place. Currently, nothing on the OpenJDK web site gives 
the answer. (Some Group pages indicate which packages are maintained by 
the Group, but the information is incomplete and presented differently 
by each Group.)

Consequently, I strongly support formalizing the association between the 
JDK Project's codebase and the mailing lists (proxies for Groups and 
Projects) that maintain it.

Transitory errors in the association (such as "the hotspot interpreter 
belongs to runtime not hotspot compiler") can be fixed, and do not mean 
the association is fundamentally unreasonable or unnecessary.

Whether the association should be operationalized in Skara tooling in 
exactly the way Robin described, is a separate topic. Whether the 
granularity of the association should be per file, per directory, per 
module, or a mix thereof, is also a separate topic.

Alex

On 8/27/2020 6:26 AM, David Holmes wrote:
> In all seriousness I just don't think this is a reasonable or necessary 
> thing to do. When you create a PR you should specify the mailing lists 
> to be used, as you do today with a RFR. Trying to maintain a file by 
> file mapping is just a huge initial setup cost and a maintenance 
> nightmare. It is not necessary to try and automate this IMO.
> 
> I wish this intent had been flagged/discussed some time ago. :(
> 
> David
> -----
> 
> On 27/08/2020 8:34 pm, Robin Westberg wrote:
>> Hi all,
>>
>> As part of transitioning the jdk/jdk repository to Git with project 
>> Skara, we have created a set of rules that determine which mailing 
>> list(s) should be the default recipient of a review request, depending 
>> on which files are changed. The initial version of these rules was 
>> created by looking at historical commits and matching them with 
>> existing mailing list review threads. This has produced a reasonable 
>> basis, but it can most certainly be made better with some additional 
>> manual curating.
>>
>> Therefore, it would be very helpful if people with good knowledge of 
>> the various subsystems and source files that make up the JDK would be 
>> willing to take a look at these rules, and also suggest improvements 
>> where needed. In addition, lists like [1] would also be very useful 
>> insofar they exist.
>>
>> The current version of these rules is located in a JSON file in the 
>> Skara repository at [2]. In order to check the validity of the rules, 
>> there is also a CLI tool that can be used to apply it to either a 
>> subset of files or existing commits and produce a suggestion [3] [4]. 
>> If you are interested in helping out with curating these rules, these 
>> are the steps to get started:
>>
>> 1. Install the Skara CLI tools: 
>> https://wiki.openjdk.java.net/display/SKARA/CLI+Tools
>> 2. Locate a suitable clone of the jdk/jdk repository (either Mercurial 
>> or Git is fine)
>> 3. Change (cd) to the root of your jdk/jdk repository
>> 3. Run the “debug mlrules” command on your favorite subset of files, 
>> for example like this (use the actual location of jdk.json on your 
>> system):
>>
>> $ git skara debug mlrules -v 
>> ~/git/skara/config/mailinglist/rules/jdk.json src/hotspot/share/jfr/
>> Reading rules file...
>> src/hotspot/share/jfr/dcmd: [hotspot-jfr-dev]
>> src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.cpp: 
>> [hotspot-jfr-dev]
>> src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.hpp: 
>> [hotspot-jfr-dev]
>> src/hotspot/share/jfr/instrumentation/jfrJvmtiAgent.cpp: 
>> [hotspot-jfr-dev, serviceability-dev]
>>>> Final list suggestion is: [hotspot-jfr-dev, serviceability-dev]
>>
>> The command accepts multiple folder and/or file names to make it 
>> possible to simulate a potential change to a given set of files:
>>
>> $ git skara debug mlrules -v 
>> ../skara/config/mailinglist/rules/jdk.json doc/ide.md 
>> src/hotspot/cpu/x86/x86.ad src/hotspot/os/linux/gc/z/zNUMA_linux.cpp
>> Reading rules file...
>> doc: [build-dev]
>> src/hotspot/cpu: [hotspot-compiler-dev]
>> src/hotspot/os: [hotspot-runtime-dev, hotspot-gc-dev]
>>
>> Combined list suggestion: [build-dev, hotspot-compiler-dev, 
>> hotspot-gc-dev, hotspot-runtime-dev]
>> Final list suggestion is: [build-dev, hotspot-dev]
>>
>> If the suggestions look fine, all is well. If not, you are welcome to 
>> propose a change to the rules, preferably by editing the jdk.json file 
>> [6] and creating a pull request towards the Skara project as described 
>> in [5]. Coincidentally, this is the same way that future changes to 
>> the jdk/jdk repository will be integrated, so this exercise could also 
>> serve as a way of getting started with Git / Skara!
>>
>> Best regards,
>> Robin
>>
>> [1] https://openjdk.java.net/groups/2d/2dawtfiles.html
>> [2] 
>> https://git.openjdk.java.net/skara/blob/master/config/mailinglist/rules/jdk.json 
>>
>>
>> [3]
>> $ git skara debug mlrules -v 
>> ~/git/skara/config/mailinglist/rules/jdk.json 
>> src/java.desktop/unix/native
>> Reading rules file...
>> src/java.desktop/unix/native/common: [2d-dev]
>> src/java.desktop/unix/native/include: []
>> src/java.desktop/unix/native/libawt: [2d-dev]
>> src/java.desktop/unix/native/libawt_headless: [awt-dev]
>> src/java.desktop/unix/native/libawt_xawt: [awt-dev]
>> src/java.desktop/unix/native/libfontmanager: [2d-dev]
>> src/java.desktop/unix/native/libjawt: [awt-dev]
>> src/java.desktop/unix/native/libsplashscreen: [awt-dev]
>>
>> Combined list suggestion: [2d-dev, awt-dev]
>> Final list suggestion is: [2d-dev, awt-dev]
>>
>> [4]
>> $ git skara debug mlrules -d 30 -v 
>> ~/git/skara/config/mailinglist/rules/jdk.json .
>> ...
>> ✅ [2d-dev, awt-dev, serviceability-dev] c32923e0: 8240487: Cleanup 
>> whitespace in .cc, .hh, .m, and .mm files
>> ❌ [awt-dev] 7f74c7dd: 8212226: SurfaceManager throws "Invalid Image 
>> variant" for MultiResolutionImage (Windows)
>>      Suggested lists: [2d-dev, awt-dev]
>>      Rules matching unmentioned lists [2d-dev]:
>>        src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java - 
>> [2d-dev: ^src/java.desktop/share/classes/sun/java2d/]
>>>>
>> [5] https://wiki.openjdk.java.net/display/SKARA/Skara#Skara-Workflow
>>
>> [6]
>> The rules are made up of sets of regular expressions for the various 
>> mailing lists that are used for reviewing changes going into the JDK. 
>> If any rule matches, that mailing list will get a copy of the review 
>> request email. For directories containing files that belong to 
>> different subsystems, it’s usually a good idea to write the rules in a 
>> complementary fashion if possible, so that anything not explicitly 
>> mentioned gets a reasonable default. As an example, see these rules 
>> for a subset of awt / 2d / i18n files:
>>
>> “awt-dev”: 
>> "src/java.desktop/share/classes/sun/awt/(?!font|sunhints|color/|font/|geom/|im/|image/|print/)” 
>>
>> “2d-dev”: 
>> "src/java.desktop/share/classes/sun/awt/(font|sunhints|color/|font/|geom/|image/|print/)" 
>>
>> “I18n-dev”: "src/java.desktop/share/classes/sun/awt/im/“
>>
>> In this example, anything not explicitly indicated as belonging to 
>> either 2d-dev or i18-dev will be matched by awt-dev.
>>


More information about the jdk-dev mailing list