Re: Git pull ack emails..

[Kees Cook]

On Tue, Oct 23, 2018 at 1:41 AM, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> So I've got a few options:
>
>  - just don't do it

As with other folks, this is what we're used to, but it does cause a
lot of "polling" your tree to see what's landed. (And your "Pulled"
email to pstore today scared the crap out of me briefly -- it made me
go look for this thread...)

I enjoyed getting Greg's "Pulled" emails for post-rc4, since it closes
the loop. I've always hugely preferred getting "Applied" etc emails,
and I try to make sure I always send them too.

>  - acking the pull request before it's validated and finalized.

While this can work, I would find it personally only a little useful
since it doesn't actually contain the information I (and any folks
contributing to the pulled patches) need: has it landed? When I send a
pull request for security hardening things, I'm mentally wearing my
seasoned asbestos suit until I see the PR has landed. (Other trees of
mine like pstore don't tend to trigger rants, so those are likely just
fine for this notification method.)

>  - starting the reply when doing the pull, leaving the email open in a
> separate window, going on to the next pull request, and then when
> build tests are done and I'll start the next one, finish off the old
> pending email.

This sounds like an annoying fragmentation of your workflow. I thought
Mark and Kirill's suggestion to stash the PR Message-Id in your merge
commit would be pretty easy to automate, though. (And may just be a
good bit of record-keeping anyway...)

On the balance, I think since most things you start to pull are, in
fact, pulled, the "send at start" method covers most cases and does
let people know when you've gotten to their PR. And I can spend less
time wearing my preparatory asbestos -- just from "Pulled" email until
I see it land. ;)

-- 
Kees Cook