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? Although, having a patchwork maintainer in the community might make maintaining our own infrastructure less costly. > 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. > 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. Glenn _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel