-
Enhancement
-
Resolution: Unresolved
-
P3
-
None
-
None
-
None
There are two distinct problems with how the Skara bots associate labels with PRs, but I believe they would benefit from being fixed together.
The first problem is that the list of rules associating certain files in the repository with mailing lists/PR labels does not reside in the JDK repo itself, but in the Skara repo. This makes it more awkward and complicated for JDK devleopers to update this information. It also seems conceptually wrong -- this is definitely information that belongs to the source code repo. For instance, seeSKARA-2446, where the rules were not updated to match changes in the source code.
The second problem is that the files is conceptually the inverse mapping of what we should have. It starts with a label, and then lists all files and directories that belong to that label. Unfortunately, this approach creates two problems:
1) We miss files and directories. There are still files and directories in the code base that are not covered by any labels. PRs touching those files will essentially go unnoticed. Even worse, they might get approved more or less by someone stumbling upon them, even though they have not been reviewed by developers from the area that really should have known about them.
2) It is very hard for submitters to understand what labels/ares their code changes are belonging to. For instance, if you do mechanical changes that touch large parts of the code base, the assumed OpenJDK custom is that you split this PR into multiple ones, one per label. However, due to the structure of the current mapping between files and labels, it is tricky to deduce this beforehand, and any attempt to do this is just based on educated guesses. (This also relates the question on how it is hard for newcomers to understand what mailing lists to use when they want to discuss/socialize PR ideas they have.)
The first problem is that the list of rules associating certain files in the repository with mailing lists/PR labels does not reside in the JDK repo itself, but in the Skara repo. This makes it more awkward and complicated for JDK devleopers to update this information. It also seems conceptually wrong -- this is definitely information that belongs to the source code repo. For instance, see
The second problem is that the files is conceptually the inverse mapping of what we should have. It starts with a label, and then lists all files and directories that belong to that label. Unfortunately, this approach creates two problems:
1) We miss files and directories. There are still files and directories in the code base that are not covered by any labels. PRs touching those files will essentially go unnoticed. Even worse, they might get approved more or less by someone stumbling upon them, even though they have not been reviewed by developers from the area that really should have known about them.
2) It is very hard for submitters to understand what labels/ares their code changes are belonging to. For instance, if you do mechanical changes that touch large parts of the code base, the assumed OpenJDK custom is that you split this PR into multiple ones, one per label. However, due to the structure of the current mapping between files and labels, it is tricky to deduce this beforehand, and any attempt to do this is just based on educated guesses. (This also relates the question on how it is hard for newcomers to understand what mailing lists to use when they want to discuss/socialize PR ideas they have.)