Core Toolchain Infrastructure - October 2024 update

[Joseph Myers]

On Wed, 30 Oct 2024, Mark Wielaard wrote:

> Yes, we did already discuss this. But it is too early for that. Richard
> setup a wiki page for the Forge Experiment that includes a list of
> various bugs/issues in Forgejo that we would like to see resolved
> before we can call the experiment an success.
> https://gcc.gnu.org/wiki/ForgeExperiment
> When we are a bit further into the experiment to know which ones are
> real blockers, we could fund the work to get those done.

There is also my long list of considerations at 
https://gcc.gnu.org/pipermail/gcc/2024-September/244806.html for 
evaluation - it's not just a few specific issues, there are lots of things 
to evaluate.  Some may be supported well already, some may need more work 
on the ForgeJo side, some may involve significant local scripting to 
combine with existing or new APIs on the ForgeJo side.

I don't think there's any real evaluation been done yet of what email 
notifications can be set up to go to mailing lists and what those 
notifications look like (for pull requests, commits, etc.) and how much is 
configurable there or needs custom scripting, or of what configuration is 
available for checks on commits that are allowed to enter either the 
repository at all or specific branches thereof (both commits pushed 
directly and commits merged via PRs) - but such checks are certainly 
important to avoid various subsequent automation (e.g. the nightly cron 
jobs) falling over.  (I expect many of these things to involve some kind 
of configuration hooks that link into appropriate APIs / scripting we'd 
need to provide, rather than ForgeJo having configuration options that 
directly match what we want.)  Likewise, for API support sufficient for 
people to build their own efficient workflows for reviewing lots of 
patches, where they currently have such workflows based on email.

As discussed in the previous thread, such evaluation would probably take a 
narrative form discussing how desired features relate to what ForgeJo 
provides, not checkbox yes/no for each item, and so provide a basis for 
further consideration of what we achieve through appropriate hooks / 
scripting, what we seek to get added as ForgeJo features (possibly paying 
for features to be implemented) and what we might end up deciding is less 
important or has underlying goals that can be achieved in a different way.

Each toolchain project may reach its own conclusions about what's 
important for possibly moving to a forge - we don't have any group that 
makes decisions for the toolchain as a whole, and each project has its own 
existing hooks and other scripting / automation that would need adapting.

-- 
Joseph S. Myers
josmyers@redhat.com