I mentioned most/all of these ideas for cfbot at some point. I'm writing them now so other people know about them and they're in once place.
- Keep the original patch series and commit messages, rather than squishing them into a single commit with cfbot's own commit messages. Maybe append an empty commit with cfbot's message, and include a parsable "base-branch: NNN" commit hash. This supports some CI ideas like making HTML available for patches touching doc/ (which needs to be relative to some other commit to show only the changes rather than every *.html). And code coverage report for changed files, which has the same requirement. That *also* allows directly reviewing the original patch series with a branch maintained by cfbot, preserving the patch set, with commit messages. See also: https://www.postgresql.org/message-id/flat/CAKU4AWoU-P1zPS5hmiXpto6WGLOqk27VgCrxSKE2mgX%3DfypV6Q%40mail.gmail.com Alternate idea: submit the patch to cirrus as a PR which makes the "base branch" available to cirrus as an environment variable (note that PRs also change a couple of other cirrus behaviors). - I think cfbot already keeps track of historic CI build results (pass/fail and link to cirrus). But I don't think cfbot exposes this yet. I know cirrus can show history for a branch, but I can never find it, and their history is limited. This would be like the buildfarm pages, ordered by time: one showing all results, one showing all failures, and one showing all results for a given patch. You could also consider retrieving the cirrus logs themselves, to allow setting our own retention interval (we could ask cirrus if they'd want to allow setting more aggressive expiration for logs/artifacts). - HTML: sort by CF ID rather than alpha sort. Right now, commitfest entries beginning with a capital letter sort first, which at least one person seems to have discovered. - HTML: add a "queued for CI" page showing the next patches to be submitted to cirrus. These pages might allow queueing a re-run, too. - HTML: show "target version" and "committer" (maybe committer name would be shown in the existing list of names, but with another style applied). This helps to distinguish between patches which someone optimistically said was RFC and a patch which a committer intends to commit, which ought to be pretty visible so it's not lost in the mailing list and a surprise to anyone. - index on CF ID without CFNUM - reasons that you mentioned that I can't remember (like maybe cirrus history and rebuilds at end of each CF).