All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Rob Herring <robh@kernel.org>
Cc: Dmitry Vyukov <dvyukov@google.com>,
	Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
	users@linux.kernel.org, workflows@vger.kernel.org
Subject: Re: RFC: Github PR bot questions
Date: Thu, 17 Jun 2021 17:24:50 +0200	[thread overview]
Message-ID: <20210617172450.05f91115@coco.lan> (raw)
In-Reply-To: <CAL_JsqJNriy1HwY-A-4Qczt-MNvMh0zOvWhvd0DAX3EHm6hhNw@mail.gmail.com>

Em Thu, 17 Jun 2021 08:33:29 -0600
Rob Herring <robh@kernel.org> escreveu:

> On Thu, Jun 17, 2021 at 2:55 AM Mauro Carvalho Chehab
> <mchehab+huawei@kernel.org> wrote:
> >
> > Em Thu, 17 Jun 2021 10:20:31 +0200
> > Dmitry Vyukov <dvyukov@google.com> escreveu:
> >  
> > > On Thu, Jun 17, 2021 at 8:53 AM Mauro Carvalho Chehab
> > > <mchehab+huawei@kernel.org> wrote:  
> > > >
> > > > Em Wed, 16 Jun 2021 15:11:33 -0600
> > > > Rob Herring <robh@kernel.org> escreveu:
> > > >  
> > > > > On Wed, Jun 16, 2021 at 11:18 AM Konstantin Ryabitsev
> > > > > <konstantin@linuxfoundation.org> 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.  
> > >
> > > I think this system needs to use get_maintainer.pl results as is and
> > > any fixing/filtering/sanity checking needs to go into
> > > get_maintainer.pl itself.
> > > get_maintainer.pl 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
> > > get_maintainer.pl when sending a one-off patch to another subsystem
> > > (what else?).
> > >
> > > I don't see where we are getting if we accept get_maintainer.pl
> > > 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 get_maintainer.pl is to
> > > start using it. In fact it's already widely used as is, so I am not
> > > sure it's particularly bad.  
> >
> > I'm not saying that get_maintainer.pl produces bad result. Depending
> > on what is done, it could produce a very large output.
> >
> > Let's suppose that someone do something like globally renaming a
> > widely-used kAPI, e. g. something like:
> >
> >         $ git ls-files|xargs sed s,mutex_,new_mutex_, -i
> >
> > A change like that would touch lots of subsystems, making get_maintainer.pl
> > to spend a lot of time processing it, and producing thousands of
> > entries (btw, we had a change somewhat similar to the above a long time
> > ago when mutex API was introduced and most of the semaphores were converted
> > to use mutex kAPI instead).  
> 
> What I end up doing in those cases is only Cc'ing the subsystem
> maintainers. But that's a manual step of dropping all the driver and
> SoC maintainers.

Yeah, surely it would be a lot better if the maintainer's file would
have a way to distinguish between driver and subsystem maintainers.

> A related problem is if you want to put who should
> apply the patch on To. That's maybe as simple as whether the
> maintainer entry has a git tree. 

It is not that simple. Driver maintainers usually also point to the
subsystem's tree.

One way would be to look at the committer for the file.

Another one would be to check if there are multiple maintainers
for the same file, with different entries. If so, the first
entry is the driver maintainer, and the last one, the subsystem
maintainer. Yet, this is heuristics, and may lead to errors.

Thanks,
Mauro

  reply	other threads:[~2021-06-17 15:24 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-16 17:18 RFC: Github PR bot questions Konstantin Ryabitsev
2021-06-16 17:24 ` Drew DeVault
2021-06-16 17:47 ` Johannes Berg
2021-06-16 17:55   ` Konstantin Ryabitsev
2021-06-16 18:13     ` Miguel Ojeda
2021-06-17 17:07       ` Serge E. Hallyn
     [not found] ` <CAJhbpm_BgbSx581HU0mTCkcE28n_hRx=tv74az_mE2VBmPtrVA@mail.gmail.com>
2021-06-16 18:05   ` Konstantin Ryabitsev
2021-06-16 18:11 ` Miguel Ojeda
2021-06-16 18:22   ` Konstantin Ryabitsev
2021-06-16 18:38     ` Miguel Ojeda
2021-06-16 20:10 ` Willy Tarreau
2021-06-17 15:11   ` Konstantin Ryabitsev
2021-06-17 15:25     ` Willy Tarreau
2021-06-16 20:24 ` Linus Torvalds
2021-06-17 15:09   ` Konstantin Ryabitsev
2021-06-16 21:11 ` Rob Herring
2021-06-16 21:18   ` Stefano Stabellini
2021-06-16 21:59     ` Rob Herring
2021-06-16 22:33   ` James Bottomley
2021-06-17 14:18     ` Rob Herring
2021-06-17 14:27       ` James Bottomley
2021-06-17  6:52   ` Mauro Carvalho Chehab
2021-06-17  8:20     ` Dmitry Vyukov
2021-06-17  8:55       ` Mauro Carvalho Chehab
2021-06-17  9:33         ` Dmitry Vyukov
2021-06-17  9:52           ` Geert Uytterhoeven
2021-06-17 14:33         ` Rob Herring
2021-06-17 15:24           ` Mauro Carvalho Chehab [this message]
2021-06-17 15:38             ` Rob Herring
2021-06-17 15:45             ` Christoph Hellwig
2021-06-17 14:02     ` Rob Herring
2021-06-17 14:47   ` Konstantin Ryabitsev
2021-06-17 15:25     ` Steven Rostedt
2021-06-17 15:48       ` Christoph Hellwig
2021-06-17 15:53         ` Laurent Pinchart
2021-06-17 17:15     ` Rob Herring
2021-06-17  6:37 ` Dmitry Vyukov
2021-06-17  7:30 ` Greg KH
2021-06-17 14:59   ` Konstantin Ryabitsev
2021-06-17  8:24 ` Christoph Hellwig
2021-06-17  8:33   ` Jiri Kosina
2021-06-17  9:52     ` Dmitry Vyukov
2021-06-17 10:09       ` Christoph Hellwig
2021-06-17 14:57         ` Konstantin Ryabitsev
2021-06-17 15:16           ` Mark Brown
2021-06-17 15:24             ` Laurent Pinchart
2021-06-17 16:36               ` Geert Uytterhoeven
2021-06-17 18:43               ` Miguel Ojeda
2021-06-17 15:31             ` Paolo Bonzini
2021-06-17 17:06               ` Stefano Stabellini
2021-06-17 22:35                 ` Jiri Kosina
2021-06-17 14:23       ` Miguel Ojeda
2021-06-17 20:42 ` Brendan Higgins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210617172450.05f91115@coco.lan \
    --to=mchehab+huawei@kernel.org \
    --cc=dvyukov@google.com \
    --cc=konstantin@linuxfoundation.org \
    --cc=robh@kernel.org \
    --cc=users@linux.kernel.org \
    --cc=workflows@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.