linux-kernel - Re: Git pull ack emails..

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wjVJ1w=MYXhu42+1rPybtztz+7q=KWo53nQmasR7R4SNA@mail.gmail.com>
Date:   Thu, 25 Oct 2018 07:13:59 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     kirill@...temov.name, Linus Walleij <linus.walleij@...aro.org>,
        Boris Brezillon <boris.brezillon@...tlin.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Christoph Hellwig <hch@....de>,
        Guenter Roeck <linux@...ck-us.net>,
        Jacek Anaszewski <jacek.anaszewski@...il.com>,
        Jens Axboe <axboe@...nel.dk>, Mark Brown <broonie@...nel.org>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Git pull ack emails..

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".

But this might be one of those "maybe a quick prototype gives people
ideas". Sometimes people _really_ hate automation, but it sounds to me
like it would be a lovely thing to have.

                    Linus