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

Konstantin Ryabitsev
2019-09-03T17:27:13Z

On Tue, Sep 03, 2019 at 09:07:00AM -0700, Linus Torvalds wrote:
>I think some of the push-back to the GPU people wasn't from them not
>inventing the group maintainership like Dave said, but from that being
>presented as some kind of "this is the way to do it". When it's just
>_one_ way to do it, and other groups have completely different
>infrastructure and models..
>
>So I don't think we can force some workflows.

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)?
- would you (or your employer entity) be willing to participate in a
fundraiser to help fund the development of such tool (in case we
cannot get the LF to fully fund it)?
- would it be okay if the tool is written in NPM/javascript?

Okay, just kidding about the NPM bit. ;)

-K