Glenn Washburn <developm...@efficientek.com> writes: > On Sun, 14 Feb 2021 13:58:40 +1100 > Daniel Axtens <d...@axtens.net> wrote: > >> > 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. > > That's great. I'm thinking it would be better to use somebody else's > infrastructure instead of maintaining our own, like maintaining our own > patchwork server. I'm a little surprised that there's not a centralized > multiproject patchwork server with lots of projects that use MLs for > sending patches. Or have I just not seen it?
patchwork.kernel.org patchwork.ozlabs.org would be the two big deployments > Although, having a patchwork maintainer in the community might make > maintaining our own infrastructure less costly. Not as much as you might thing, unfortunately. >> 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. > > That's great, but we're still maintaining the infrastructure. But maybe > we've got people in our community that are willing to contribute those > resources. Neither of the multiproject patchworks have builtin CI infrastructure, unfortunately. >> 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. > > I think having automated building/testing of patches would be great. > And the bot could reply to the first email in the patch thread with > success/failure and some links to logs or other artifacts. I don't > really like the custom solution aspect cause that's more overall > maintenance. This is why I like the potential of the sourcehut > suggestion. Fair. Kind regards, Daniel > > Glenn _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel