Re: RFC: Github PR bot questions

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


On Thu, Jun 17, 2021 at 8:53 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,, 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 or it would get
> > who to send to based on GH repo and reviewers? Without work on
> >, 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.

I think this system needs to use results as is and
any fixing/filtering/sanity checking needs to go into itself. is what is used by lots of contributors, the only
option for any automated systems, what is used by new contributors if
they don't use this system anyway. And even experienced developers
know internal rules only for a few subsystems and use when sending a one-off patch to another subsystem
(what else?).

I don't see where we are getting if we accept
produces bad results and needs additional fixing in every system out
there (dozens) and when used by humans. All systems would need the
same filtering/checking rules and they need to keep in sync. What a
kernel developer would even need to do to fix something (add/remove
themselves)? Go and talk to a large unknown set of systems that
duplicate the same additional rules?

And the only way to surface actual issues with is to
start using it. In fact it's already widely used as is, so I am not
sure it's particularly bad.

[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