LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Rob Herring <rob.herring@linaro.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: kirill@shutemov.name, Linus Walleij <linus.walleij@linaro.org>,
	boris.brezillon@bootlin.com,
	Catalin Marinas <catalin.marinas@arm.com>,
	Christoph Hellwig <hch@lst.de>,
	Guenter Roeck <linux@roeck-us.net>,
	jacek.anaszewski@gmail.com, axboe@kernel.dk,
	Mark Brown <broonie@kernel.org>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Git pull ack emails..
Date: Fri, 26 Oct 2018 12:36:14 -0500	[thread overview]
Message-ID: <CABGGiszsw=QXPwTe3mf26BG=Pxig6zGcXXJfRA+w0Pawrm5qpQ@mail.gmail.com> (raw)
In-Reply-To: <CAHk-=wjVJ1w=MYXhu42+1rPybtztz+7q=KWo53nQmasR7R4SNA@mail.gmail.com>

On Thu, Oct 25, 2018 at 9:14 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> I'm back home, slightly jetl-agged, but _oh_ so relieved to not be
> doing the merge window on a laptop any more.
>
> I've been continuing to just manually ack the pull requests, but I've
> almost forgotten a few times (and maybe I _did_ forget one or two and
> didn't catch it? Who knows?).
>
> So while maybe just continuing to do this means that it becomes second
> nature, I'm starting to think that mailing list automation really
> would be a good idea:
>
> On Tue, Oct 23, 2018 at 1:04 PM Konstantin Ryabitsev
> <konstantin@linuxfoundation.org> wrote:
> >
> > On Tue, Oct 23, 2018 at 10:46:06AM +0100, Linus Torvalds wrote:
> > >If it's a "proper" pull request (ie done by git request-pull), then
> > >the magic marker would be that it as that
> > >
> > >    for you to fetch changes up to %H:
> > >
> > >line where %H is the hash of the tip of the tree that is requested to be pulled.
> > >
> > >Then automation could literally just check "is that commit in Linus'
> > >public tree", and when that happens, generate an automatic
> > >notification that the pull request in question has been merged.
> >
> > I can probably do something like that at kernel.org. How about something
> > more generic -- e.g. a simple tool that asks a remote web service to
> > notify you when a commit-id is seen in one of the kernel.org repos?
>
> So I think it might be good to have some generic model for "give me a
> trigger when XYZ hits git tree ABC" that people could just do in
> general, *but* I think the "scan mailing lists for regular pull
> requests" would actually be nicer.
>
> Maybe it would be just a special-case wrapper around a more generic
> thing, but this:
>
> > - send a REST request to https://foo.kerkel.org/lmk:
> >
> >   {
> >     "tree": "mainline",
> >     "commit": "123abc...abc555",
> >     "notify": "(output of $(git config user.email)"
> >   }
>
> doesn't really sound all that nice for the "I sent a git pull request,
> and want to be notified".
>
> It would be much nicer if the "notification" really did the right
> thing, and created an actual email follow-up, with the correct To/Cc
> and subject lines, but also the proper "References" line so that it
> actually gets threaded properly too.
>
> That implies that it really should be integrated into the mailing list itself.
>
> But I don't know how flexible the whole lkml archive bot is for things
> like this. But I assume you have _some_ hook into new messages coming
> in for lore.kernel.org?
>
> > Would that be a useful alternative? If yes, what would be your preferred
> > workflow for such tool instead of "git lmk [commit] [tree-moniker]"?
>
> I really do suspect that "I sent out a pull request, I'd like to be
> automatically notified when it gets upstream" would be the primary
> thing.
>
> And by "upstreamed" it isn't necessarily just my tree, of course.
>
> Are there other situations where you might want to track something
> _outside_ of a pull request? Maybe. I can't really think of a lot of
> them, though. Patches etc don't have commit ID's to track, but it
> *might* be interesting to see similar automation just based on the git
> patch-ID. But that sounds more like a patchwork issue than something
> like "track pull requests".

I would very much like to see something that works for patches too.
There's a lot of tribal knowledge needed for submitters to learn as to
what is each maintainer's process. Reducing that would be beneficial
IMO, and more solvable than discussions around non-email based
submissions. For example, with Greg and Mark B you can expect an
automated replies. Mark's reply gets threaded with the original, but
Greg's do not. For networking, you may or may not get a manual reply,
but patchwork always has the status if you know to go check it. In
reviewing patches I want to know the status too, but that's somewhat
my unique position of reviewing bindings which mostly other
maintainers apply. I've somewhat solved it for myself by automating
checking linux-next, but maybe automated email replies to patches
being in linux-next would be nice. While that's not immediate, it
should be quick enough. And I'd like to have automated replies sent on
patches I apply, but I'm lazy and haven't managed to set that up yet.

BTW, patchwork tracks pull requests too, so maybe there's a common solution.

Rob

  reply	other threads:[~2018-10-26 17:36 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-23  8:41 Linus Torvalds
2018-10-23  8:53 ` Linus Walleij
2018-10-23  9:10   ` Linus Torvalds
2018-10-23  9:35     ` Kirill A. Shutemov
2018-10-23  9:45       ` Mark Brown
2018-10-23  9:46       ` Linus Torvalds
2018-10-23 20:04         ` Konstantin Ryabitsev
2018-10-25 14:13           ` Linus Torvalds
2018-10-26 17:36             ` Rob Herring [this message]
2018-10-26 21:15               ` Mark Brown
2018-11-01 10:18                 ` Michael Ellerman
2018-11-07 10:41                   ` Boris Brezillon
2018-11-07 23:56                     ` Michael Ellerman
2018-10-31 14:27             ` Konstantin Ryabitsev
2018-10-31 18:34               ` Linus Torvalds
2018-10-23  9:02 ` Willy Tarreau
2018-10-23  9:15   ` Linus Torvalds
2018-10-23  9:23   ` Takashi Iwai
2018-10-23  9:15 ` Ingo Molnar
2018-10-23  9:17 ` Boris Brezillon
2018-10-23  9:47   ` Mark Brown
2018-10-23  9:19 ` Mark Brown
2018-10-23  9:25 ` Greg KH
2018-10-23  9:51 ` James Morris
2018-10-23  9:56 ` Jens Axboe
2018-10-23 12:13 ` Ulf Hansson
2018-10-23 20:41   ` Jacek Anaszewski
2018-10-23 20:01 ` Olof Johansson
2018-10-24 22:21 ` Kees Cook

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='CABGGiszsw=QXPwTe3mf26BG=Pxig6zGcXXJfRA+w0Pawrm5qpQ@mail.gmail.com' \
    --to=rob.herring@linaro.org \
    --cc=axboe@kernel.dk \
    --cc=boris.brezillon@bootlin.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@lst.de \
    --cc=jacek.anaszewski@gmail.com \
    --cc=kirill@shutemov.name \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=torvalds@linux-foundation.org \
    --cc=ulf.hansson@linaro.org \
    --subject='Re: Git pull ack emails..' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).