Re: RFC: Github PR bot questions

[Dmitry Vyukov <dvyukov@google.com>]

think On Wed, Jun 16, 2021 at 7:18 PM 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:
>
> - 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
> - 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)
> - 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)?

Hi Konstantin,

This is exciting!
I think it will be more useful in the long run to have it on a single
github repo with multiple branches (single point of submission). The
advantages I see are:
 - having single integration point with testing systems
 - no version skew, no broken deployments that need maintenance
 - no radically different configurations, these rules are like code
style (does not matter which one exactly we use as long as it's
consistent across the project)
 - much higher RoI for testing/CI/tool experts contributions (this
addresses one of the main pain points of the current kernel testing --
it's simply not possible to contribute to it. Why would I contribute
only to a single subsystem testing that runs on somebody's personal
machine which may disappear tomorrow? and how do I even choose one
subsystem if I don't have personal interest in any?)
I also assume that lots of maintainers either won't have lots of
interest in configuring/maintaining this, or will have some interest
initially but will lose it over time.
For once: it will be possible to have proper documentation on the
process (as compared to current per-subsystem rules, which are usually
not documented again because of low RoI for anything related to a
single subsystem only).

If we have a single point of submission, will it be possible to have
some per-branch/subsystem settings? If yes, that may be a good
compromise: having a well-defined set of preferences (maintainer can
choose A or B, or opt-in into a new static check or not) that are
managed centrally.



> - 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. :)
>
> I'll probably have more questions as I go along, but I wanted to start with
> these two.
>
> Thanks,
> -K