Messages in this thread | | | From | Rob Herring <> | Date | Fri, 26 Oct 2018 12:36:14 -0500 | Subject | Re: Git pull ack emails.. |
| |
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
| |