Re: RFC: Github PR bot questions

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


On Wed, Jun 16, 2021 at 10: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:

Neat! I have been going from the other direction, trying to take
patches sent to LKML (actually from the kselftest mailing list) and
upload them to Gerrit:

My thinking was that most developers would want to keep sending
patches via git-send-email, but sometimes it is really nice to have a
side-by side diff without having to download a patch and apply it
somewhere. Also, sometimes it is nice to have all the comments on code
in a single place (I have got it able to extract comments from emails
- although not super reliably).

I was thinking it might be nice to be able to go both directions, but
it had not been on the top of my priority list.

> - submitters would no longer need to navigate their way around
>   git-format-patch,, and git-send-email -- nor would need to
>   have a patch-friendly outgoing mail gateway to properly contribute patches

I like having the tools run automatically, that was something I wanted
to do with my LKML-Gerrit-Bridge at some point.

> - 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 multiple times)

That would be awesome!

> - the bot should (eventually) be clever enough to automatically track v1..vX
>   on pull request updates, assuming the API makes it straightforward

Yeah, that's something I have wanted to do with the
LKML-Gerrit-Bridge. This would be super awesome!

> 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
>   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 would like to be able to run KUnit tests, and I am sure other
maintainers would want to run other tests. Beyond that, I don't think
I would want to deviate from your above defaults too much.

> - We can *probably* track when patch series get applied and auto-close pull
>   requests that are accepted -- but it's not going to be perfect (we'd
>   basically be using git-patch-id to match commits to pull requests). Or is it
>   better to auto-close the pull request right after it's sent to the list with
>   a message like "thank you, please monitor your email for the rest of the
>   process"? The latter is much easier for me, of course. :)

That would be super awesome as well. My plan with the
LKML-Gerrit-Bridge was to leave it open until applied and then have
some sort of timeout.

> I'll probably have more questions as I go along, but I wanted to start with
> these two.

Not sure how far along you are with this. But I would love to see this
happen. It sounds like you are planning on supporting most of the
features I am trying to get in LKML-Gerrit-Bridge, but not all - I
mainly would like to get patches uploaded from the mailing lists. I am
not sure how much we could collaborate here depending on how far along
you are. I saw some concerns in some other emails about relying on
open source, Gerrit could be a solution to that. Anyway, let me know
if you are interested in my project. You can see my code here:

Also note, I said "I" above, but I have gotten some contributions from
others. I'm not trying to take credit away from them, more that I
don't want them to take blame for any of my bad ideas. Also, this is
in NO WAY a plug for my project. It's not very stable right now, and
has some issues - it is very experimental. I am just hoping that it
can maybe be of some help to you.


[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