From: Rob Herring <robh@kernel.org>
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Cc: users@linux.kernel.org, workflows@vger.kernel.org
Subject: Re: RFC: Github PR bot questions
Date: Wed, 16 Jun 2021 15:11:33 -0600 [thread overview]
Message-ID: <CAL_JsqLMPnCpEHpbj_=LDQNU9+sq5oFrmSxngdiWNR3XOhtc_Q@mail.gmail.com> (raw)
In-Reply-To: <20210616171813.bwvu6mtl4ltotf7p@nitro.local>
On Wed, Jun 16, 2021 at 11:18 AM Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> Hi, all:
>
> I've been doing some work on the "github-pr-to-ml" bot that can monitor GitHub
> pull requests on a project and convert them into fully well-formed patch
> series. This would be a one-way operation, effectively turning Github into a
> fancy "git-send-email" replacement. That said, it would have the following
> benefits for both submitters and maintainers:
What makes this specific to Github PRs? A Github PR is really just a
git branch plus a target at least to the extent we would use it here.
The more of this that works on just a git branch, the more widely
useful it would be.
> - submitters would no longer need to navigate their way around
> git-format-patch, get_maintainer.pl, and git-send-email -- nor would need to
> have a patch-friendly outgoing mail gateway to properly contribute patches
Presumably, the bot would rely on get_maintainer.pl or it would get
who to send to based on GH repo and reviewers? Without work on
get_maintainer.pl, I don't think it will work well beyond simple
cases.
> - subsystem maintainers can configure whatever CI pre-checks they want before
> the series is sent to them for review (and we can work on a library of
> Github actions, so nobody needs to reimplement checkpatch.pl multiple times)
What about all the patches that don't come from the GH PR? Those need
CI pre-checks too. We're going to implement CI twice? The biggest
issue I have on CI checks is applying patches. My algorithm is apply
to my current base (last rc1 typically) or give up. I'm sure it could
be a lot smarter trying several branches or looking at base-commit
(not consistently used) or the git diff treeish hashes. What I'd
really like is some bot or script that's applying series and
publishing git branches with a messageid to git branch tool. 0-day is
doing this now. Basically, the opposite direction as others have
mentioned.
> - the bot should (eventually) be clever enough to automatically track v1..vX
> on pull request updates, assuming the API makes it straightforward
>
> A this point, I need your input to make sure I'm not going down any wrong
> paths:
>
> - My general assumption is that putting this bot on github.com/torvalds/linux
> would not be useful, as this will probably result in more noise than signal.
> I expect that subsystem maintainers would prefer to configure their own
> GitHub projects so they can have full control on what kind of CI prechecks
> must succeed before the series is sent out. Is that a valid assumption, or
> should I be working towards having a single point of submission on each
> forge platform (Github, Gitlab, etc)?
I think it needs to be per maintainer in terms of what checks run, but
if submission is per maintainer project then the problem will be how
does the submitter know where to send something? get_maintainer.pl
tells them? It doesn't do a great job of that IMO. There's not a clear
distinction of who applies my patch and others Cc'ed (file
maintainers).
I've kind of reached the conclusion that relying on submitters to get
it right is never going to work (is Cc the DT list for DT patches so
PW picks them up so hard!?). I think the model needs to be send
patches to 'the kernel' and then maintainers have tools to extract all
the patches they are interested in (the planned lore
local-email-interface).
I'm sure there are maintainers who want nothing to do with Github or
anything else. So it's got to work without any maintainer involvement.
The submitter can't be expected to figure out who will and will not
take GH PR based submissions.
Rob
next prev parent reply other threads:[~2021-06-16 21:11 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-16 17:18 RFC: Github PR bot questions Konstantin Ryabitsev
2021-06-16 17:24 ` Drew DeVault
2021-06-16 17:47 ` Johannes Berg
2021-06-16 17:55 ` Konstantin Ryabitsev
2021-06-16 18:13 ` Miguel Ojeda
2021-06-17 17:07 ` Serge E. Hallyn
[not found] ` <CAJhbpm_BgbSx581HU0mTCkcE28n_hRx=tv74az_mE2VBmPtrVA@mail.gmail.com>
2021-06-16 18:05 ` Konstantin Ryabitsev
2021-06-16 18:11 ` Miguel Ojeda
2021-06-16 18:22 ` Konstantin Ryabitsev
2021-06-16 18:38 ` Miguel Ojeda
2021-06-16 20:10 ` Willy Tarreau
2021-06-17 15:11 ` Konstantin Ryabitsev
2021-06-17 15:25 ` Willy Tarreau
2021-06-16 20:24 ` Linus Torvalds
2021-06-17 15:09 ` Konstantin Ryabitsev
2021-06-16 21:11 ` Rob Herring [this message]
2021-06-16 21:18 ` Stefano Stabellini
2021-06-16 21:59 ` Rob Herring
2021-06-16 22:33 ` James Bottomley
2021-06-17 14:18 ` Rob Herring
2021-06-17 14:27 ` James Bottomley
2021-06-17 6:52 ` Mauro Carvalho Chehab
2021-06-17 8:20 ` Dmitry Vyukov
2021-06-17 8:55 ` Mauro Carvalho Chehab
2021-06-17 9:33 ` Dmitry Vyukov
2021-06-17 9:52 ` Geert Uytterhoeven
2021-06-17 14:33 ` Rob Herring
2021-06-17 15:24 ` Mauro Carvalho Chehab
2021-06-17 15:38 ` Rob Herring
2021-06-17 15:45 ` Christoph Hellwig
2021-06-17 14:02 ` Rob Herring
2021-06-17 14:47 ` Konstantin Ryabitsev
2021-06-17 15:25 ` Steven Rostedt
2021-06-17 15:48 ` Christoph Hellwig
2021-06-17 15:53 ` Laurent Pinchart
2021-06-17 17:15 ` Rob Herring
2021-06-17 6:37 ` Dmitry Vyukov
2021-06-17 7:30 ` Greg KH
2021-06-17 14:59 ` Konstantin Ryabitsev
2021-06-17 8:24 ` Christoph Hellwig
2021-06-17 8:33 ` Jiri Kosina
2021-06-17 9:52 ` Dmitry Vyukov
2021-06-17 10:09 ` Christoph Hellwig
2021-06-17 14:57 ` Konstantin Ryabitsev
2021-06-17 15:16 ` Mark Brown
2021-06-17 15:24 ` Laurent Pinchart
2021-06-17 16:36 ` Geert Uytterhoeven
2021-06-17 18:43 ` Miguel Ojeda
2021-06-17 15:31 ` Paolo Bonzini
2021-06-17 17:06 ` Stefano Stabellini
2021-06-17 22:35 ` Jiri Kosina
2021-06-17 14:23 ` Miguel Ojeda
2021-06-17 20:42 ` Brendan Higgins
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='CAL_JsqLMPnCpEHpbj_=LDQNU9+sq5oFrmSxngdiWNR3XOhtc_Q@mail.gmail.com' \
--to=robh@kernel.org \
--cc=konstantin@linuxfoundation.org \
--cc=users@linux.kernel.org \
--cc=workflows@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.