| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
Make it possible to print more debugging information when (re)generating
a subsystem list.
Include parent inference details to the source code itself and add a
-debug flag to list the source files assigned to each subsystem.
|
| |
|
|
|
|
|
|
|
| |
There was a mistake in the Linux subsystem generation rules that led to
the exclusion of exfat-related syz_mount_image calls from the resulting
subsystem descriptions.
Verify the rules before applying them. Fix other problems found by the
check.
|
| |
|
|
|
|
| |
Our fs is more generic than it was defined in MAINTAINERS. Let's not
spam its mailing lists with bugs from individual filesystem
implementations.
|
| |
|
|
| |
It will help keep more generic reports in "net".
|
| |
|
|
|
| |
If a record was specified in a custom subsystem list, do not consider it
while grouping records by mailing list.
|
| |
|
|
|
|
| |
For some subsystems (e.g. `kernel`) such reports just don't make much
sense, since there are too many incorrectly classified bugs in there.
Make it possible to exclude such subsystems from periodic reminders.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Earlier we only took maintainers if there was just one MAINTAINERS
record, but that was a very severe limitation.
Let's try a more elaborate approach. It's also not perfect, but allows
us to extract many more maintainers, while keeping false positives at
zero.
Group raw MAINTAINER records by their T: entries. If there's just one
set of T: values per group mailing list, take the intersection of M:
entries from there.
|
| |
|
|
|
|
|
| |
There are cases when a subsystem doesn't have a mailing list and yet
we'd prefer not to merge it with others. Let's add the ability to add
custom rules that join several specified MAINTAINERS records into one
Subsystem.
|
| |
|
|
|
|
| |
Remove the entity and match subpackages.
Regenerate the linux.go file.
|
| |
|
|
|
|
|
|
| |
In the previous steps we eliminate some of the extracted subsystems. It
helps to have fewer contention while assigning the names.
As a result, we need to only rely on emails during parents
trasnformations.
|
| |
|
|
| |
Simplify the code by removing the unnecessary itermediate structures.
|
| |
|
|
|
|
| |
Despite the automatic logic we already have, there are still a few
emails that slip the check. For now let's keep them in a separate array,
maybe later we'll figure out a pattern.
|
| |
|
|
|
| |
This list was generated using an older version of the code. It'll serve
as a baseline for further changes.
|
| |
|
|
|
| |
We don't really care about Documentation/ and similar folders. Exclude
such path matching rules after parsing MAINTAINERS.
|
| |
|
|
|
|
|
|
|
| |
For that, extract a coincidence count matrix from a path coverage, then
apply the following rule.
Subsystem A is a child of B if both hold true:
1) More than 2/3 of paths that relate to A also relate to B.
2) B covers more directory tree entities than A.
|
| |
|
|
| |
Otherwise we can get too many mailing lists at the same time.
|
| |
|
|
| |
This information will let us extract subsystems from reproducers.
|
| |
|
|
|
|
|
|
|
| |
Extract the short subsystem name from the mailing list email.
Stip the common prefixes and suffixes and make sure there are no
duplicates.
As a fallback, assign the whole list email address as a subsystem name.
|
| |
|
