Messages in this thread | | | From | Linus Torvalds <> | Date | Thu, 25 Oct 2018 07:13:59 -0700 | 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@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".
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
| |