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