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. > > 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 > > > 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 >
