ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <bjorn.helgaas@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	Laura Abbott <labbott@redhat.com>,
	Bjorn Helgaas <helgaas@kernel.org>,
	"ksummit-discuss@lists.linuxfoundation.org"
	<ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] Topics for the Maintainer's Summit
Date: Tue, 3 Sep 2019 12:40:18 -0500	[thread overview]
Message-ID: <CABhMZUUzyMXyKthjt31qU-p-2=6s2Cvw5jb=bw3=T76kzfUyKA@mail.gmail.com> (raw)
In-Reply-To: <20190903172708.qrvaad2paze6ifhz@chatter.i7.local>

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.

  reply	other threads:[~2019-09-03 17:40 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-30  3:17 [Ksummit-discuss] Topics for the Maintainer's Summit Theodore Y. Ts'o
2019-08-30 12:01 ` Wolfram Sang
2019-08-30 13:58 ` Shuah Khan
2019-08-30 14:36   ` shuah
2019-08-30 13:58 ` Bjorn Helgaas
2019-09-02 15:09   ` Shuah Khan
2019-09-02 20:42   ` Dave Airlie
2019-09-02 22:22     ` Theodore Y. Ts'o
2019-09-03  2:35       ` Olof Johansson
2019-09-03  3:05         ` Randy Dunlap
2019-09-03 13:29       ` Laura Abbott
2019-09-03 16:07         ` Linus Torvalds
2019-09-03 17:27           ` Konstantin Ryabitsev
2019-09-03 17:40             ` Bjorn Helgaas [this message]
2019-09-06 10:21               ` Rob Herring
2019-09-19  1:47                 ` Bjorn Helgaas
2019-09-19 20:52                   ` Rob Herring
2019-09-20 13:37                     ` Mark Brown
2019-09-03 17:57             ` Mark Brown
2019-09-03 18:14             ` Dan Williams
2019-09-03 21:59             ` Wolfram Sang
2019-09-04  8:34             ` Jan Kara
2019-09-04 12:08             ` Laurent Pinchart
2019-09-04 13:47               ` Konstantin Ryabitsev
2019-09-05  8:21                 ` Jani Nikula
2019-09-06 10:50                   ` Rob Herring
2019-09-06 19:21                     ` Linus Torvalds
2019-09-06 19:53                       ` Olof Johansson
2019-09-09  8:40                         ` Jani Nikula
2019-09-09  9:49                           ` Geert Uytterhoeven
2019-09-09 10:16                             ` Konstantin Ryabitsev
2019-09-09 10:59                               ` Geert Uytterhoeven
2019-09-09 12:37                                 ` Konstantin Ryabitsev
     [not found]                     ` <20190911095305.36104206A1@mail.kernel.org>
2019-09-11 11:03                       ` Christoph Hellwig
2019-09-13  8:19                       ` Matthias Brugger
2019-09-05  7:01           ` Jani Nikula
2019-09-05 15:26             ` Theodore Y. Ts'o

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CABhMZUUzyMXyKthjt31qU-p-2=6s2Cvw5jb=bw3=T76kzfUyKA@mail.gmail.com' \
    --to=bjorn.helgaas@gmail.com \
    --cc=bjorn@helgaas.com \
    --cc=helgaas@kernel.org \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=labbott@redhat.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).