On 08/10/2025 17:52, Jonathan Wakely wrote:
On Wed, 8 Oct 2025 at 17:43, Richard Earnshaw (lists) via Gcc
<[email protected]> wrote:
The gcc-TEST repository in the forge
(https://forge.sourceware.org/gcc/gcc-TEST) already has a few labels that were
manually created in order to support those participating in the experiment. At
present these have to be added manually to each pull request.
But there's an opportunity to do much better than that and to automatically
assign a number of labels based on the components that a patch touches.
The attached file is my initial stab (technically it's my second, but I posted
that only to the forge mailing list and in reply to another message, so it has
probably been lost by now) at such a taxonomy of labels. Once I have a largely
finalized list, I expect to use the REST API in the forge to bulk create the
labels.
My ultimate goal is that we would be able to map patches to components (most
likely determined via a script that mapped affected files to components) and
then components to mailing lists and reviewers, so that they would be notified
of new pull requests being submitted. This initial mapping should be automated
with a runner in the forge, but labels can then be manually changed by
reviewers.
I'm looking for feedback on this list since it's much easier to add labels in
bulk than it is to change labels once they start being applied to pulls.
Thoughts?
Nice. Should there be something for docs?
These mostly seem like they could be classified as Build/xxx rather
than General/xxx:
General/config Affects configure or autoconf scripts
General/make Affects Makefiles or automake
General/unknown Catch-all, does not match any other category
General/gdbhooks Support for debugging GCC with GDB (gdbhooks.py)
But maybe it makes sense to have a more ... general ... grouping than Build.
Would Misc be better for all of these? I think docs would fit under
that; but do we need Docs/* for the different components in the tools?
R
