On Wed, Jun 16, 2021 at 11:18 AM 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: What makes this specific to Github PRs? A Github PR is really just a git branch plus a target at least to the extent we would use it here. The more of this that works on just a git branch, the more widely useful it would be. > - 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 Presumably, the bot would rely on get_maintainer.pl or it would get who to send to based on GH repo and reviewers? Without work on get_maintainer.pl, I don't think it will work well beyond simple cases. > - 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) What about all the patches that don't come from the GH PR? Those need CI pre-checks too. We're going to implement CI twice? The biggest issue I have on CI checks is applying patches. My algorithm is apply to my current base (last rc1 typically) or give up. I'm sure it could be a lot smarter trying several branches or looking at base-commit (not consistently used) or the git diff treeish hashes. What I'd really like is some bot or script that's applying series and publishing git branches with a messageid to git branch tool. 0-day is doing this now. Basically, the opposite direction as others have mentioned. > - 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)? I think it needs to be per maintainer in terms of what checks run, but if submission is per maintainer project then the problem will be how does the submitter know where to send something? get_maintainer.pl tells them? It doesn't do a great job of that IMO. There's not a clear distinction of who applies my patch and others Cc'ed (file maintainers). I've kind of reached the conclusion that relying on submitters to get it right is never going to work (is Cc the DT list for DT patches so PW picks them up so hard!?). I think the model needs to be send patches to 'the kernel' and then maintainers have tools to extract all the patches they are interested in (the planned lore local-email-interface). I'm sure there are maintainers who want nothing to do with Github or anything else. So it's got to work without any maintainer involvement. The submitter can't be expected to figure out who will and will not take GH PR based submissions. Rob
