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.
next prev parent 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).