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 josmy...@redhat.com
