Apologies, I forgot to CC the forge list with this followup.
R.
On 28/10/2025 14:10, Richard Earnshaw via Gcc wrote:
> This is a second pass at setting up some labels for use in the forge.
> This time though, I've added some additional data that is intended to
> be the begginings of an automated way of applying labels to merge
> requests.
>
> The idea here is that a script in the forge will be able to
> automatically apply a label to a pull request if the rule (surrounded
> by '{}' matches). As a demonstration I'm also including a simple
> python script that can be used to demonstrate some parts of this,
> though it hasn't been finished or polished enough yet to work on a
> patch - though that shouldn't be too hard to adapt to python's unidiff
> module.
>
> For the file matches I've devised a franken file-globbing syntax: it's
> a bit more powerful than standard glob patterns, but a bit more suited
> to matching filenames than full regular expressions. The python script
> will take this and adapt it into a normal pythonic regular expression.
>
> To reduce the number of labels that some files will pick up, whilst
> keeping things compact, the format also supports a limited number of
> priority levels. These are numbered from 1 to 9, with 1 being the
> highest priority. If no priority is given (&<priority> at the start
> of the file pattern, then the default is priority 1. Only matching
> labels from the highest priority group are used; any from lower groups
> are discarded. For example, if there were three labels, that matched
> the file gcc/rtl.h
>
> midend/rtl (priority 2)
> midend/misc (priority 4)
> midend/rtl-ssa (priority 2)
>
> then only midend/rtl and midend/rtl-ssa would be selected. Note that
> this is a fictitious example, just for illustration.
>
> At some point I'll probably convert the labels file to some more
> structured data format; this will allow for a cleaner representation
> of the data and avoid the need for such long lines. Likely candidates
> are json (but that doesn't really support comments) or yaml, but that
> needs importing a suitable parser as python doesn't have one in the
> core library. We could of course use an extended json format that
> we pre-process to remove any comments.
>
> In addition to all of the above, I've added a few more labels since
> last time, to fill some obvious holes that I missed. I expect the
> list to continue to evolve as this gets closer to deployment.
>
> Note that this is still very much work-in-progress; I don't expect
> this to be committed as-is unless other people really want to work on
> it. I certainly won't be enabling it yet...
>
> Richard Earnshaw (1):
> forge: utilities to support classifying patches on the forge
>
> contrib/forge/classify.py | 158 +++++++++++++++++
> contrib/forge/labels | 347 ++++++++++++++++++++++++++++++++++++++
> 2 files changed, 505 insertions(+)
> create mode 100755 contrib/forge/classify.py
> create mode 100644 contrib/forge/labels
>
