LKML Archive on
help / color / mirror / Atom feed
From: Ingo Molnar <>
To: Linus Torvalds <>
Cc: Boris Brezillon <>,
	Catalin Marinas <>,
	Christoph Hellwig <>,
	Guenter Roeck <>,
	Jacek Anaszewski <>,
	Jens Axboe <>,
	Linus Walleij <>,
	Mark Brown <>,
	Ulf Hansson <>,
	Greg KH <>,
	Linux Kernel Mailing List <>
Subject: Re: Git pull ack emails..
Date: Tue, 23 Oct 2018 11:15:03 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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



  parent reply	other threads:[~2018-10-23  9:15 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-23  8:41 Linus Torvalds
2018-10-23  8:53 ` Linus Walleij
2018-10-23  9:10   ` Linus Torvalds
2018-10-23  9:35     ` Kirill A. Shutemov
2018-10-23  9:45       ` Mark Brown
2018-10-23  9:46       ` Linus Torvalds
2018-10-23 20:04         ` Konstantin Ryabitsev
2018-10-25 14:13           ` Linus Torvalds
2018-10-26 17:36             ` Rob Herring
2018-10-26 21:15               ` Mark Brown
2018-11-01 10:18                 ` Michael Ellerman
2018-11-07 10:41                   ` Boris Brezillon
2018-11-07 23:56                     ` Michael Ellerman
2018-10-31 14:27             ` Konstantin Ryabitsev
2018-10-31 18:34               ` Linus Torvalds
2018-10-23  9:02 ` Willy Tarreau
2018-10-23  9:15   ` Linus Torvalds
2018-10-23  9:23   ` Takashi Iwai
2018-10-23  9:15 ` Ingo Molnar [this message]
2018-10-23  9:17 ` Boris Brezillon
2018-10-23  9:47   ` Mark Brown
2018-10-23  9:19 ` Mark Brown
2018-10-23  9:25 ` Greg KH
2018-10-23  9:51 ` James Morris
2018-10-23  9:56 ` Jens Axboe
2018-10-23 12:13 ` Ulf Hansson
2018-10-23 20:41   ` Jacek Anaszewski
2018-10-23 20:01 ` Olof Johansson
2018-10-24 22:21 ` Kees Cook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: Git pull ack emails..' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).