Re: RFC: Grub project management

[Glenn Washburn]

On Sun, 14 Feb 2021 13:58:40 +1100
Daniel Axtens <dja@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