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