Message-ID: <CABGGiszsw=QXPwTe3mf26BG=Pxig6zGcXXJfRA+w0Pawrm5qpQ@mail.gmail.com>
Date:   Fri, 26 Oct 2018 12:36:14 -0500
From:   Rob Herring <rob.herring@...aro.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     kirill@...temov.name, Linus Walleij <linus.walleij@...aro.org>,
        boris.brezillon@...tlin.com,
        Catalin Marinas <catalin.marinas@....com>,
        Christoph Hellwig <hch@....de>,
        Guenter Roeck <linux@...ck-us.net>, jacek.anaszewski@...il.com,
        axboe@...nel.dk, Mark Brown <broonie@...nel.org>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Git pull ack emails..

On Thu, Oct 25, 2018 at 9:14 AM Linus Torvalds
<torvalds@...ux-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@...uxfoundation.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

Powered by blists - more mailing lists