Hey everyone, Patchwork has been having lots of issues recently, dropping patches, being unusably slow and generally starting to become more of a pain than help. Over on the CI side we are also not super fond of it and we don't have enough resources to maintain it properly. Lucas has suggested using public-inbox archives directly, and with some recent tools like b4/lei making common ML workflows feasible without reinventing the wheel, we are considering setting up a bridge between MLs and GitHub/GitLab to instead drive CI using more modern tools. We have not decided whether to drop Patchwork yet - this is a thread to gather people's thoughts if this sounds like a good idea. The workflow would look like this: - A drm-tip mirror would be set up on GitHub/fd.o GitLab, automatically pulling all changes from drm-tip upstream fd.o GitLab as a secondary source. - For each new series on lore.kernel.org a bridge would create a PR by taking the latest mirrored drm-tip source, then applying a new series with `b4 shazam`. - That PR would then go through the normal CI flow, with CI checks being reported on that PR, instead of sending all the reports to the mailing list. - On the mailing list, the bridge would send an ack that a series has been seen and where are its results. You would no longer receive multiple emails with KBs of logs in your email client, but everything would be available from PR checks (as status checks and links to full logs only, no trimming and "last 1000 lines only"). - Mirrors, PRs and checks for public mailing lists would be public, much like on the current public Patchwork instance. - Logs behind links will be stored for a few months (3-6, depends on traffic and how the situation evolves). GitHub Checks themselves (check status, shortlogs and links) have a hard retention period of 400 days. - Not sure about PR retention: we need a mechanism to correctly identify merged series somehow, then to trim these from the list. Expected retention time? - Not sure about reporting on "CI finished": Maybe we could send one more email with a summary of checks when the entire workflow has been finished? On GitHub vs fd.o GitLab: I'm thinking more of GitHub here: - GitHub generally performs better with large repositories. - Extra fallback drm-tip source for fd.o downtime periods. - Bonus points: We can store public Intel CI tags directly in that mirror for moderate periods of time without abusing fd.o servers. Either option would work fine though, so opinions here would be appreciated :) CI itself would not run in the native forge CI either way, but rather on our Jenkins infra, as it does today. If there's ever a need to switch forges, it would require reworking the bridging/reporting bits, but not *all* the bits. We don't want to self-host another forge as we don't have enough people and free time to do that properly. Codeberg, etc are not an option due to the drm-tip repo size. And that's the initial idea. Thoughts? Do you like any of this, or does it sound like a downgrade from what we have today? Thanks, Ryszard
