On 02/06/2026 08:39, Richard Biener wrote: > On Fri, May 29, 2026 at 5:17 PM Richard Earnshaw via Sourceware Forge > <[email protected]> wrote: >> >> Hi gcc-patches mailing list, >> Richard Earnshaw via Sourceware Forge >> <[email protected]> has requested that the >> following forgejo pull request >> be published on the mailing list. >> >> Created on: 2026-05-29 15:13:48+00:00 >> Latest update: 2026-05-29 15:16:32+00:00 >> Changes: 3 changed files, 6198 additions, 12 deletions >> Head revision: rearnsha/gcc-TEST ref MAINT-yaml commit >> 528143f5f8d97be480cc2ab945ea338a7b461f77 >> Base revision: gcc/gcc-TEST ref trunk commit >> 8653813b1e4377bf01c3b1a45c11b9616f5886fe r17-981-g8653813b1e4377 >> Merge base: 8653813b1e4377bf01c3b1a45c11b9616f5886fe >> Full diff url: https://forge.sourceware.org/gcc/gcc-TEST/pulls/163.diff >> Discussion: https://forge.sourceware.org/gcc/gcc-TEST/pulls/163 >> Requested Reviewers: >> >> RFD: convert MAINTAINERS data to YAML. >> >> For the forge to be able to notify maintainers efficiently when a >> merge request is submitted, I need to be able to automate assigning >> reviewers as well as just labels. The information needed for this is >> largely in the MAINTAINERS file, but not in a format that is readily >> machine readable: it can be scraped, but it's a bit of an ad-hoc >> process and not something I'd want to maintain in the long term. >> >> To mitigate that, and to make it possible to augment this information >> with additional details, I've been experimenting with converting the >> raw data into YAML and then having a script build the official >> MAINTAINERS file form that. The results can be seen in the following >> patch. The results so far are /almost/ identical with only a limited >> set of differences, some of which can probably be resolved later on. >> >> - the free-form entries saying All XXX maintainers have been expanded >> into explicit lists; I really don't think it helps much to have yet >> another level of indirection to deal with here and in particular it >> complicates regenerating the MAINTAINERS file as the template rules >> would need to be handled specifically. >> >> - I've found some small sort-order differences; these could be easily >> rectified, but I think the sort order I'm using here >> (case-independent sort) is preferable to a case-dependent one: Lac >> should be sorted before LaD. It would be better, I think to tweak >> check-MAINTAINERS.py to prefer this new order, but that file becomes >> redundant if this code goes in. >> >> - I might have over-merged the entries for Feng Wang. That's easily >> fixable in the MAINTAINERS.yml data, but is an example of the kind >> of issue that I've faced with creating the machine-readable data >> from the raw files. >> >> Finally, the name for Naveen Gowda has changed in the DCO list. The >> email address used appears elsewhere in the MAINTAINERS file with a >> slightly different name. This could be fixed with a small extension >> to the YAML data (the DCO entry could take an optional name), if it >> really matters. >> >> One additional field that I've added is a marker for what I consider >> to be inactive accounts. The forge is likely to be more aggressive in >> emailing developers and I don't want it to be forever mailing people >> who have long ceased to contribute to the project. For now I've >> scraped the GCC commit logs and posts to [email protected] and >> [email protected]; anybody who has not contributed to one of those >> sources in the last two years has been marked as inactive. The >> generator script has an option (-a) to build a version of the >> MAINTAINERS file with inactive users removed: we have a lot of retired >> devs! >> >> This patch isn't ready to commit yet. Before I do that I need to >> write a schema checker for the YAML data and to add some additional >> checks for the consistency of the data; but there's no point in adding >> that until we have agreed on the basic format. Finally the full list >> of sources for the active developers needs to be agreed: are the three >> sources above enough, or should we be scraping more lists from the >> project? >> >> --- >> >> Convert the existing MAINTAINERS data to YAML and add a script to >> rebuild the MAINTAINERS file from it. > > Can we do it the other way around? And .. YAML? Ick. >
Not really. The problem is that the existing data is not reliably machine readable. Even to generate the current version of the .yml file I had to hand edit it at the end as there's no reliable way of correlating all the information. As for YAML, for this data it's straight forward... and certainly better than JSON as at least it officially supports comments. >> >> ChangeLog: >> >> * MAINTAINERS: Regenerate from MAINTAINERS.yml >> >> contrib/ChangeLog: >> >> * MAINTAINERS.yml: New file. >> * gen-MAINTAINERS.py: New file. >> >> Thanks for taking the time to contribute to GCC! >> >> Please be advised that https://forge.sourceware.org/ is currently a trial >> that is being used by the GCC community to experiment with a new workflow >> based on pull requests. >> >> Pull requests sent here may be forgotten or ignored. Patches that you want to >> propose for inclusion in GCC should use the existing email-based workflow, >> see https://gcc.gnu.org/contribute.html >> >> >> Changed files: >> - A: contrib/MAINTAINERS.yml > > This location also seems wrong then. > >> - A: contrib/gen-MAINTAINERS.py >> - M: MAINTAINERS >> This is just an RFD. I don't mind where the data ends up in the file structure. Living alongside the MAINTAINERS file would be fine by me. R. >> >> Richard Earnshaw (1): >> MAINTAINERS: convert to a generated file >> >> MAINTAINERS | 29 +- >> contrib/MAINTAINERS.yml | 5898 ++++++++++++++++++++++++++++++++++++ >> contrib/gen-MAINTAINERS.py | 283 ++ >> 3 files changed, 6198 insertions(+), 12 deletions(-) >> create mode 100644 contrib/MAINTAINERS.yml >> create mode 100755 contrib/gen-MAINTAINERS.py >> >> -- >> 2.54.0 >>
