On Thu, Jun 17, 2021 at 12:52 AM Mauro Carvalho Chehab <mchehab+huawei@xxxxxxxxxx> wrote: > > Em Wed, 16 Jun 2021 15:11:33 -0600 > Rob Herring <robh@xxxxxxxxxx> escreveu: > > > 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. > > Some sanity test is needed, as otherwise it will end by trying to send > the patch to a large number of people. > > > > > > - 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. > > Finding the common parent for a PR is easy. In the case of github, > all the script need is to get the common ancestor between the forked > tree (from where the PR originated) and the tree where the PR is being > submitted. I'm not interested in doing it in Github. It's about applying a patch from a list, so how would Github help there anyways? It's not easy in git either because there's not a command to do it AFAIK. I suspect much of what's needed exists as git-am can find the merge base. I think it's something like for a given set of branches or refs, which ones match all the base treeishs in the diff. Then you'd know for certain that the patch would apply to those branches. If that doesn't work, then you could fallback to just try to apply patches to different branches. It would be nice if the fallback could work without doing a checkout though. > It shouldn't be hard to add this at a patch 00/xx. Not hard and we have that with base-commit, but that's left up to the submitter. I don't use base-commit in my patches because it's more work. For example, it doesn't work if you didn't setup a tracking branch. In general, for anything left up to the submitter, we have to deal with the submitter not doing it. If it is built-in to the tools (git) then we can start relying on it. Maybe if patch 0 became more automated like a git PR email, then it would work. But then what happens on single patches without a cover. Rob
