Re: on when to checksum

From: Linus Torvalds <torvalds@osdl.org>
Date: May 2, 2005, 19:57 UTC
Message-ID: <Pine.LNX.4.58.0505021250450.3594@ppc970.osdl.org>
In-Reply-To: <200505021921.MAA26977@emf.net>

On Mon, 2 May 2005, Tom Lord wrote:

> 
> I'm curious about what is the value of the "batch" nature of that
> proces?

My time.

I don't know about other people, but I don't multitask. I do one thing, and that's it. I don't move my mouse around. I sit in my mail reader, and I read email. I don't read one email, switch to another window, apply it, swithc back, read the next email etc etc.

In fact, I claim that anybody who works that way is going to have an IQ of about 15 points lower than somebody who batches things up. Just because you end up losing your context, and that effectively makes you stupid.

Concentration is a wonderful thing, but it _requires_ that you do things in a concentrated manner.

> So, if I understand, you review each change before stuffing it in a
> mailbox, then you apply all the patches in that mailbox in batch.
> In the majority of cases, the buffering of changes in the mailbox
> adds nothing.

I read email, and while reading email I save the interesting ones off to another mbox (I call mine "doit"). They get saved off for "later perusal".

I do a first-order review at that stage, and in fact, 95% of the time, what goes into the "doit" folder _will_ get applied. Not 100%, though, exactly because at this stage I just read email and work in a mail-reader: I don't usually even look at the actual kernel sources that a patch involves. In particular, sometimes it turns out that the patch wasn't against my version at all, but against a -mm tree, and I just don't even worry about technical details at that stage.

Stage #2 is going through the "doit" folder at some later date (maybe a couple of times a day), and going through it one more time. Maybe not that much more "carefully", but with a different intent - now I actually check sign-offs, add my own, and check out the actual problems in the source tree if needed.

Stage #3 is actually applying it.

_Each_ stage culls out bad things.

And I _really_ don't bounce between stages.

> In other words, a more asynchronous process might save you time *and*
> pay off by reserving more of your attention for areas where it's 
> really needed.

It's not asynchronous. It's batched in different stages so that I can work better. And latency matters.

		Linus