Re: [Ksummit-discuss] Topics for the Maintainer's Summit

Bjorn Helgaas
2019-09-03T17:40:31Z

On Tue, Sep 3, 2019 at 12:27 PM Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:

> For quite some time now I've been trying to fund some client-side
> tooling development around public-inbox (the software that drives
> lore.kernel.org). Eric Wong (the principal author of public-inbox), and
> I have had lengthy chats about potential functionality of such tool, and
> what we envision can be described as "local patchwork with a mutt-like
> interface":
>
> - It would use public-inbox repositories to track new patches and
> conversations, so it would no longer be necessary to subscribe to the
> actual mailing list(s). Getting new mail would be equivalent to a "git
> pull".
> - It would have an equivalent of notmuch search, so instead of needing
> to go to lore.kernel.org, you could search the entire mailing list
> locally and perform actions on the results found.
> - Just like Patchwork, it would keep track of new patches and series of
> patches, recognize when new patch/series revisions are posted, track
> reviewed-by's, tested-by's, etc, and provide useful maintainer
> functionality, such as showing interdiffs between revisions.
> - Patches and series can be pre-filtered by keywords or file paths (e.g.
> if you're only interested in arch/arm64/mm/.*, the tool would ignore
> any patches/revisions not touching files in that dir).
> - It would support creating workflows and conditional response actions,
> e.g. "create new branch, apply this series, run these test suites; if
> tests succeed, merge into branch `for-linus`; if merge successful,
> reply to submitter with 'thanks, applied!'; if all went well, archive
> the series; if any steps failed, flag the series for my review".
> - The workflows would run in the background, including using external
> systems if preferred. Maintainers can contribute their workflows to a
> shared repository so others can easily copy and adapt them.
>
> That's obviously not a complete list, but it seems to me that something
> like this would be quite welcome by a lot of maintainers (at least,
> everyone I've talked to about this got really excited). Eric Wong is
> quite willing to work on something like this, but he is not in a
> position to donate so much of his time and effort (especially on top of
> maintaining public-inbox) -- so if we want to see this happen, we need
> to come up with some funds.
>
> I've inquired internally at the Foundation, and while there's general
> willingness to fund such initiatives, the People In Charge Of Money want
> to see a buy-in from maintainers. The natural instinct is to talk to
> Greg, but I believe he's quite happy with his workflow, so while I'm
> sure he'd be happy to feign excitement, he's unlikely to be interested
> in the tool. Linus is not the right person to talk to either, because he
> doesn't deal with patches and tests, so wouldn't benefit from such tool.
>
> So, my plan was to track down Shuah (who's also at the Foundation) and
> Laura (who is on the TAB) at the upcoming summit to float this idea with
> them to see what they think. However, since we're talking about
> lore.kernel.org, tooling and workflows quite a bit already, I figured
> I'll bring this up here as well.
>
> It just seems that every maintainer I spoke with is generally making
> things "sort-of work well enough" by applying a lot of baling wire
> around mail clients, patchwork.kernel.org, gitlab, or all of the above,
> and I'm wondering if everyone is happy to do that, or only doing that
> because a good tool written to fit with the "kernel development model"
> doesn't exist.
>
> So:
>
> - would a tool with such functionality be useful, or would every
> maintainer prefer to continue doing their own thing (in slightly
> different ways)?

I would find something like this incredibly useful. I currently use
patchwork, but I am really sick of the only-when-online, mouse-around,
clickety-click, wait-for-the-web model.