> Reading more about patchwork, it seems to have its own set of issues, > partly revolving around using a mailing list of development as we do. > see: https://lwn.net/Articles/773456/
I'm a patchwork maintainer, happy to discuss how Patchwork might be helpful. It certainly isn't perfect (and alternatives like patchew and the freedesktop.org fork of patchwork should be seriously considered) but it certainly could be part of a solution. It doesn't directly host CI, but provides some API access that can be used to drive CI. The snowpatch project provides a link to Jenkins, although Jenkins comes with its own set of problems. A nice thing about all of upstream patchwork/FDO patchwork/patchew is that they can all be bolted on to the existing ML and be used as much or as little as desired. Another option, and something I have been considering but so far have lacked the time to do, is to set up something like one of the various bots that lurks on the linux kernel mailing lists and builds and tests patches without a web interface - just posting the results back to the ML as a reply. This could be done without any buy-in from maintainers. Kind regards, Daniel > >> Aside: the evaluation is *very* critical of gitlab.com, though it >> considers self-hosted gitlab CE should alleviate a bunch of the listed >> concerns. > > That evaluation wasn't clear on where the captcha was used. I can't > recall ever seeing a captcha on their site, certainly not on a regular > basis. I wonder how hard the GNU position would be against using GitLab > in the manner I suggest (modifying my original comment about requiring > merge requests for CI, but having it optional). Most of their > complaints seem to be around javascript. Would that be alleviated by > using scripts to do things via the API? > >> sourcehut and pagure are the likely contenders for a GNU/FSF endorsed >> forge, and sourcehut is the only software forge I'm aware of >> *anywhere* that considers mailing lists to be a/the core development >> workflow (and therefore integrates a patchwork). >> >> > I think a lot of the work done in my GitLab CI changes could be >> > reused for other CI systems or we can use just the CI part of these >> > changes. That GitLab repo should be setup already to trigger a CI >> > pipeline whenever master changes (but only once the .gitlab-ci.yml >> > file is in master). >> >> Yeah, having a somewhat independent script to run CI builds is good, >> it helps avoid getting locked into specific CI providers. :) >> >> As we've seen from e.g. >> >> https://www.theregister.com/2020/11/02/travis_ci_pricng/ >> https://news.ycombinator.com/item?id=25338983 >> >> Free CI is not guaranteed to stick around... > > Nope, nothing is. But GitLab's may last longer than others that have CI > as a core business. > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
