RFR: Initial mailing list mapping rules for the jdk repository

Kevin Rushforth kcr at openjdk.java.net
Tue Aug 25 17:44:31 UTC 2020

On Tue, 25 Aug 2020 09:43:41 GMT, Erik Helin <ehelin at openjdk.org> wrote:

>> 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
> I can't comment on the details of the rules, but looks good to me in general ��

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.


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

More information about the skara-dev mailing list