grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: Grub project management


From: Daniel Axtens
Subject: Re: RFC: Grub project management
Date: Fri, 19 Feb 2021 17:30:31 +1100

Glenn Washburn <development@efficientek.com> writes:

> 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?

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]