RFC: Github PR bot questions

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


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

- 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)?

- 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.


[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