Re: RFC: Github PR bot questions

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


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

[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