Re: Git pull ack emails..

[Ingo Molnar <mingo@kernel.org>]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> So I've got a few options:
> 
>  - just don't do it
> 
>  - acking the pull request before it's validated and finalized.
> 
>  - 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.
> 
> and obviously that first option is the easiest one. I'm not sure what
> Greg did, and during the later rc's it probably doesn't matter,
> because there likely simply aren't any overlapping operations.
> 
> Because yes, the second option likely works fine in most cases, but my
> pull might not actually be final *if* something goes bad (where  bad
> might be just "oops, my tests showed a semantic conflict, I'll need to
> fix up my merge" to "I'm going to have to look more closely at that
> warning" to "uhhuh, I'm going to just undo the pull entirely because
> it ended up being broken").
> 
> The third option would work reliably, and not have the "oh, my pull is
> only tentatively done" issue. It just adds an annoying back-and-forth
> switch to my workflow.

There's a fourth option I'm using: I use 'zero inbox' mail reading, 
last-to-first, and with that I can 'delay' a reply to a pull request or 
patch simply by marking the mail unread. Then when I push out tested 
trees and patches I go and process the tail of the mbox, a couple of 
entries typically. (For patches I don't even have to do anything because 
the notification is automatic and I mark the patch read when I see the 
tip-bot notification myself.)

It's still a separate workflow step but easier to manage than postponed 
emails or separate email windows, which are inevitably going to get lost 
in browser mishaps every couple of weeks, and which are not high-profile 
enough in the primary workflow either.

Might not be a practical method with the amount of mail you are getting 
though ...

> So I'm mainly pinging people I've already pulled to see how much people 
> actually _care_. Yes, the ack is nice, but do people care enough that I 
> should try to make that workflow change? Traditionally, you can see 
> that I've pulled from just seeing the end result when it actually hits 
> the public tree (which is yet another step removed from the steps above 
> - I do build tests between every pull, but I generally tend to push out 
> the end result in batches, usually a couple of times a day).
> 
> Comments?

No strong feelings here: occasionally 1 out of 40 pull requests perhaps, 
if you don't do a same-day pull or for some reason you are delaying the 
pull request (you need to time to think about it, or it's just randomly 
sorted differently from other pull requests, etc.) then I just don't know 
*why* you didn't pull: are you just thinking about it, or a random delay 
because some other tree is causing trouble and you are bisecting, or did 
it did it get lost because my email got marked spam?

I'll wait 2-3 days in such cases because when there's something genuinely 
wrong with a pull request I definitely don't want to draw your attention 
to it but figure it out myself and offer a v2 pull request ... ;-)

If you started sending Acks explicitly there would be more certainty in 
these cases.

But it's not a big factor, I'd say the efficiency of your workflow (which 
is a single thread) should be the primary concern here.

Thanks,

	Ingo