* Linus Torvalds <torva...@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
