Re: RFC: Github PR bot questions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jun 16, 2021 at 11:18 AM Konstantin Ryabitsev
<konstantin@xxxxxxxxxxxxxxxxxxx> 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



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux