Claudio Bantaloukas (rdfm) <[email protected]>) commented on the code:
ISTM this code would fit contrib/maintenance much better as forge labels are
just a subset of what it can be used for.
I'd rather there be a split between the concepts of source areas (which are
recognised by file matchers) and labels.
This would allow using source areas for other things, like assigning people for
review/maintenance, automated creation of MAINTAINERS etc
> +++ contrib/forge/classify.py
> @@ -0,0 +28,4 @@
> +
> +labels_file = 'labels'
> +
> +class classifier:
pep8: Class names should normally use the CapWords convention.
> +++ contrib/forge/classify.py
> @@ -0,0 +40,4 @@
> + self.file_class.append (self._file_entry (l.match,
> + l.full_name))
> +
> + def map_to_labels (self, name):
either doctests of this function or a full unit test file would be beneficial :)
> +++ contrib/forge/labels.yaml
> @@ -0,0 +215,4 @@
> + - group: "General"
> + exclusive: false
> + color: "006b75"
> + match_defaults:
I'd rather have the file matchers in a separate file or dictionary in this file
and have them named
> +++ contrib/forge/forgelabels.py
> @@ -0,0 +180,4 @@
> + else:
> + raise Exception (f"Group {self.group} must contain at least one
> label")
> +
> +def load():
a def check_validity() function could:
- check that dict keys are correct (either using custom code or via
jsonschema.validate
- check that every code area is composed of at least one file
- check for duplicate code area/label names
--
https://forge.sourceware.org/gcc/gcc-TEST/pulls/149#issuecomment-5783
