Date: 	Wed, 25 Apr 2001 14:31:30 -0700 (PDT)
From: Linus Torvalds <torvalds@transmeta.com>
Subject: Re: orinoco_cs & IrDA
Newsgroups: fa.linux.kernel

On Tue, 24 Apr 2001, Jean Tourrilhes wrote:
>
> 	I've got a question... I would like where to send my driver
> patches...

Probably both me and Alan.

[ General rules follow. Too few people seem to have seen them before ]

Most importantly, when sending patches to me:

 - specify clearly that you really want to see them in the standard
   kernel, and why. I occasionally get patches that just say "this is a
   good idea". I don't apply them. Especially if they are cc'd to somebody
   else too, in which case I pretty much assume that it's a RFC, not a
   "real patch".

 - do NOT send patches in attachements. Send one patch per mail, in
   clear-text under your message, so that I can easily see the patch and
   decide then-and-there whether it looks ok. And if it doesn't look ok,
   and I do a "reply", the patch gets included in the reply so that I can
   point out which part of the patch I dislike.

   Don't worry about sending me five emails. That's FINE. I much prefer
   seeing five consecutive emails from the same person with five distinct
   subject lines and five distinct patches, than seeing one email with
   five attachements to it.

 - if your email system is broken, and you want to send patches as
   attachements to avoid whitspace damage, then please FIX YOUR EMAIL
   SYSTEM INSTEAD.

 - Don't point to web-sites. If I have to move the mouse outside my email
   xterm to work on the email, your email just got ignored.

 - Make your patches one sub-directory under the source tree you're
   working on. In short, your patches should look like something like

	--- clean/fs/inode.c ...
	+++ linux/fs/inode.c ..
	@@ -179,7 +179,7 @@
	...

   so that I can (regardless of where my source tree is) apply them
   with "patch -p1" from my linux top directory. Then I can just do a

	cd v2.4/linux
	patch -p1 < ~/multiple-emails-with-multiple-accepted-patches

   and not have to worry about three patches being based on
   /usr/src/linux, while two others not having a path at all and being
   individual filenames in linux/drivers/net.

 - and finally: re-send. If I had laser-eye surgery the fay you sent the
   patches, I won't have applied them. If I took a day off and spent it
   with the kids at the pool instead, I won't have applied them. If I
   decided that this weekend I'm not going to read email for a change, I
   won't have applied them.

   And when I come back to work a day or two later, I will have several
   hundred other emails to work through. I never go backwards in my
   emails.

From: torvalds@transmeta.com (Linus Torvalds)
Subject: Re: The direction linux is taking
Date: 	Thu, 27 Dec 2001 18:05:40 +0000 (UTC)
Newsgroups: fa.linux.kernel

In article <Pine.LNX.4.33L.0112271509570.12225-100000@duckman.distro.conectiva>,
Rik van Riel  <riel@conectiva.com.br> wrote:
>On Thu, 27 Dec 2001, Russell King wrote:
>
>> I envy Alan, Linus, and Marcelo for having the ability to silently
>> drop patches and wait for resends.

This is absolutely true - it's a _very_ powerful thing. Old patches
simply grow stale: keeping track of them is not necessarily at all
useful, and can add more work than anything else. 

One of the problems I had with jitterbug was that after a while the
thing just grew a lot, and I spent a lot of time with a cumbersome web
interface just acknowledging the patches.  And that was despite the fact
that not very many people actually actively used jitterbug to submit
patches to me, so I could see it just getting a _lot_ worse. 

>I'm not going to resend more than twice. If after that
>a critical bugfix isn't applied, I'll put it in our
>kernel RPM and the rest of the world has tough luck.

Which, btw, explains why I don't consider you a kernel maintainer, Rik,
and I don't tend to apply any patches at all from you.  It's just not
worth my time to worry about people who aren't willing to sustain their
patches.

When Al Viro sends me a patch that I apply, and later sends me a fix to
it that I miss for whatever reason, I can feel comfortable in the
knowledge that he _will_ follow up, not just whine.  This makes me very
willing to apply his patches in the first place.

Replace "Al Viro" with Jeff Garzik, David Miller, Alan Cox, etc etc. See
my point?

This is not about technology.  This is about sustainable development. 
The most important part to that is the developers themselves - I refuse
to put myself in a situation where _I_ need to scale, because that would
be stupid - people simply do not scale.  So I require others to do more
of the work. Think distributed development.

Note that things like CVS do not help the fundamental problem at all. 
They allow automatic acceptance of patches, and positively _encourage_
people to "dump" their patches on other people, and not act as real
maintainers. 

We've seen this several times in Linux - David, for example, used to
maintain his CVS tree, and he ended up being rather frustrated about
having to then maintain it all and clean up the bad parts because I
didn't want to apply them (and he didn't really want me to) and he
couldn't make people clean up themselves because "once it was in, it was
in". 

I know that source control advocates say that using source control makes
it easy to revert bad stuff, but that's simply not TRUE.  It's _not_
easy to revert bad stuff.  The only way to handle bad stuff is to make
people _responsible_ for their own sh*t, and have them maintain it
themselves. 

And you refuse to do that, and then you complain when others do not want
to maintain your code for you. 

		Linus

Date: 	Thu, 27 Dec 2001 10:58:47 -0800 (PST)
From: Linus Torvalds <torvalds@transmeta.com>
Subject: Re: The direction linux is taking
Newsgroups: fa.linux.kernel

On Thu, 27 Dec 2001, Rik van Riel wrote:
>
> OK, I'll setup something to automatically send you patches
> as long as they're not applied, don't get any reaction and
> still apply cleanly.

No.

Did you read the part about "maintainership" at all?

I ignore automatic emails, the same way I ignore spam. Automating
patch-sending is _not_ maintainership.

		Linus

Date: 	Thu, 27 Dec 2001 11:25:13 -0800 (PST)
From: Linus Torvalds <torvalds@transmeta.com>
Subject: Re: The direction linux is taking
Newsgroups: fa.linux.kernel

On Thu, 27 Dec 2001, Dave Jones wrote:
> On Thu, 27 Dec 2001, Linus Torvalds wrote:
>
> > This is absolutely true - it's a _very_ powerful thing. Old patches
> > simply grow stale: keeping track of them is not necessarily at all
> > useful, and can add more work than anything else.
>
> *nod*, until they get scooped up into another tree -ac, -dj, -whatever
> and fed to you whenever you're in the mood for resyncing.

But that's nothing more than "somebody else maintains them".

I realize that quite often the author of the patch is not going to be its
maintainer, which is exactly why all the other trees are so useful.

Everybody should realize that "outside trees" are not a rogue thing. They
are _very_ important, for several reasons:

 - competition keeps people honest. If I was the only holder of the keys,
   nobody would even _know_ if I was corrupt. And nobody could choose with
   his feet.

   Look at politics: if you don't have choices, the one choice _will_ be
   corrupt even if it started out with all the best intentions. The old
   adage there is "Power corrupts. Absolute power corrupts absolutely".

 - Different taste. Let's face it, a lot of programming is about having
   taste. Sometimes I don't like the way things are done, and people prove
   me wrong by other means. See the whole thing about the VM stuff with
   Andrea's patches - one of the reasons I hadn't applied the much earlier
   patches by Andrea was that I didn't like the zone-balancing approach.

   Having external trees is _crucial_ for allowing different approaches to
   co-exist, in order to show their strengths and weaknesses. And I tend
   to be fairly open to admitting when I did something wrong, and somebody
   else had a better tree. At least I _try_.

 - Different goals. Many of the commercial vendors have vendor needs, and
   they (correctly) think that those needs are the most important thing,
   while I don't care about vendors and thus have different priorities.

   Again, multiple trees are absolutely required to make this work.

 - And imperfect patch retention. There's no question that I drop patches,
   some bad, but many good. And that's going to be true of _anybody_ who
   maintains anything, except somebody who just accepts anything without
   question (eg CVS).

I don't think I've ever spoken out against things like -ac, -dj and -aa: I
sometimes have to explain why I do not merge things whole-sale (which
would certainly be _technically_ the easiest solution much of the time),
and I often disagree with some part of the patch, but I'm actually
surprised how often I have to _defend_ having many trees.

Just a historical note: one of the things I hated most about Minix was
that while Andrew Tanenbaum allowed external patches to the system, nobody
else could make a whole distribution. Which meant that while there existed
many trees and maintainers that were "better" (notably Bruce Evans, who
was considered to be a God of Minix), they were really painful to use, in
that you had to always do it from patches.

I fully _expect_ that somebody better comes along. At some point, more
people will simply be using the -dj tree (or whatever), and that's fine.

> And when you're ready to resync what I've got so far (currently ~3mb),
> it's going to be another full time job splitting it into bits to feed
> you linus-bite-sized chunks. (ObSidenote: When this time comes btw,
> if maintainers of relevant parts want to feed Linus their relevant
> parts from my tree, that would be appreciated, and would keep _my_ load
> down :-)

This sounds absolutely wonderful..

Note that you will notice that it's a _huge_ undertaking, and one of the
things that Alan complained about was how the fact that _I_ avoid scaling
meant that he had to scale more. I think it's a very valid complaint, and
it may make a whole lot more sense (if it is possible) to have different
people caring about different parts.

Note that this may not be possible, due to lack of modularity. We've had
to actively change the tree layout of the kernel before just to make it
easier to maintain over several people. Which is painful, but not
certainly not impossible still..

> "Used to" ? cvs @ vger.samba.org was still being maintained before
> I went on xmas vacation. Did I miss something ?

Does he allow the wide and uncoordinated write access that he used to
allow? I thought he basically shut that down, and only allows a few people
now, exactly to avoid getting too horrible merge issues..

		Linus

Date: 	Thu, 27 Dec 2001 11:29:02 -0800 (PST)
From: Linus Torvalds <torvalds@transmeta.com>
Subject: Re: The direction linux is taking
Newsgroups: fa.linux.kernel

On Thu, 27 Dec 2001, Rik van Riel wrote:
>
> Of course the patch will be updated when needed, but I still
> have a few 6-month old patches lying around that still work
> as expected and don't need any change.

Sure. Automatic re-mailing can be part of the maintainership, if the
testing of the validity of the patch is also automated (ie add a automated
note that says that it has been verified).

It's just that I actually _have_ had people who just put "mail torvalds <
crap" in their cron routines. It quickly caused them to become part of my
spam-filter, and thus _nothing_ ever showed up from them, whether
automated or not..

		Linus

Date: 	Thu, 27 Dec 2001 12:21:02 -0800 (PST)
From: Linus Torvalds <torvalds@transmeta.com>
Subject: Re: The direction linux is taking
Newsgroups: fa.linux.kernel

On Thu, 27 Dec 2001, Larry McVoy wrote:
> On Thu, Dec 27, 2001 at 06:05:40PM +0000, Linus Torvalds wrote:
> > Note that things like CVS do not help the fundamental problem at all.
> > They allow automatic acceptance of patches, and positively _encourage_
> > people to "dump" their patches on other people, and not act as real
> > maintainers.
>
> Huh.  I'm not sure I understand this.  Once you accept a patch into the
> mainline source, are these people still supposed to maintain that patch?

Yes, I actually do expect them to.

It obviously depends on the kind of patch: if it is a one-liner bug-fix,
the patch is pretty much dead (that is, of course, assuming it was a
_correct_ bug-fix and didn't expose any other latent bugs).

But for most things, it's a kind of "Tag, you're it" thing. You're
supposed to support the patch (ie step up and explain what it does if
anybody wonders), and help it evolve. Many patches are only stepping
stones.

(This, btw, is something that Al Viro does absolutely beautifully. I don't
know how many people look at Al's progression of patches, but they are
stand-alone patches on their own, while at the same time _also_ being part
of a larger migration to the inscrutable goals of Al - ie namespaces etc.
You may not realize just _how_ impressive that is, and what a absolute
wonder it is to work with the guy. Poetry in patches, indeed).

> > I know that source control advocates say that using source control makes
> > it easy to revert bad stuff, but that's simply not TRUE.  It's _not_
> > easy to revert bad stuff.
>
> It's trivial to revert bad stuff if other stuff hasn't come to depend
> on that bad stuff, assuming a reasonable SCM system.

Well, there's the other part to it - most bad stuff is just "random crap",
and may not have any physical bad tendencies except to make the code
uglier. Then, people don't even realize that they are doing things the
wrong way, because they do cut-and-paste, or they just can't do things the
sane way because the badness assumes a certain layout.

And THAT is where badness is actively hurtful, while not being buggy.
Which is why I'd much rather have people work on maintenance, and not rely
on the bogus argument of "we can always undo it".

		Linus

From: torvalds@transmeta.com (Linus Torvalds)
Subject: Re: Why not "attach" patches?
Date: 	Tue, 15 Jan 2002 18:02:12 +0000 (UTC)
Newsgroups: fa.linux.kernel

In article <005901c19dec$59a89e30$0201a8c0@HOMER>,
Martin Eriksson <nitrax@giron.wox.org> wrote:
>Why do many of you not _attach_ patches instead of merging them with the
>mail? It's so much cleaner and easier to have a "xxx-yyy.patch" file
>attached to the mail which can be saved in an appropriate directory. Also,
>the whitespace is always retained that way.

Attached patches are _horrible_ once you have many patches that you want
to maintain in a sane way and apply in one go.

In particular, with in-line text patches, I can:

 - see the patch easily when reading email, without the need to do
   anything special to inspect the attachment, regardless of what email
   client I happen to use.

 - keep emails as emails, and save them to folders etc, without
   losing any information of where the patch came from, while at the
   same time the folders are _also_ the patch and work with standard
   tools like "diffstat".

 - easily just "reply" to the person, and quote the part of the patch
   I have problems with.

 - save all the emails I want to apply in one single email folder
   ("doit"), and do a simple

	patch -p1 < ~/doit

   to apply all of them at the same time.

Note that NONE of these are practical with attachments.

In short: if your mailer eats whitespace or causes similar corruption,
just FIX THE MAILER.  There is no excuse for a mailer that corrupts the
mail. 

And while attachments may _appear_ convenient, they most definitely are
not.  They require special care and cannot be batched or edited with
normal tools. 

That may not matter if you just have one or two patches a week to worry
about, but trust me - attachments are crap. Use them for binary data
that cannot be edited or combined, _not_ for stuff you expect to be able
to actually change and extract pieces of with regular tools.

		Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@transmeta.com>
Subject: Re: [Lse-tech] Re: [RFC] dcache scalability patch (2.4.17)
Original-Message-ID: <Pine.LNX.4.44.0207141708470.20233-100000@home.transmeta.com>
Date: Mon, 15 Jul 2002 00:09:00 GMT
Message-ID: <fa.l4d9mqv.1mhe2hh@ifi.uio.no>

On Sat, 13 Jul 2002, Alexander Viro wrote:
>
> So I'd just do
>
> vi fs/dcache.c -c '/|= DCACHE_R/d|/nr_un/pu|<|x'
>
> and be done with that.  Linus?

Done.

For future reference - don't anybody else try to send patches as vi
scripts, please. Yes, it's manly, but let's face it, so is bungee-jumping
with the cord tied to your testicles.

		Linus

Newsgroups: fa.linux.kernel
From: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Subject: Re: thoughts on kernel security issues
Original-Message-ID: <20050125211723.GE8859@parcelfarce.linux.theplanet.co.uk>
Date: Tue, 25 Jan 2005 21:28:08 GMT
Message-ID: <fa.ngrafkv.1m721qh@ifi.uio.no>

On Tue, Jan 25, 2005 at 03:03:04PM -0500, John Richard Moser wrote:
> > and combining them has _zero_ advantages (whatever bug the combined patch
> > fix _will_ be fixed by the series of individual patches too - even if the
> > splitting was buggy in some respect, you are pretty much guaranteed of
> > this, since the bug you were trying to fix is the _one_ thing you are
> > really testing for).
>
> Lots of work to split up a patch though.

Exactly.  And since that's a prerequisite for any meaningful review,
some equivalent of that work will have to be done at some point.
The only question is who will be doing that work - proponents of patch
or reviewers?

Look at it that way: when you are submitting a paper for publication,
it's your responsibility to get it into form that would allow review.

Sending a lump of something that might, given considerable efforts, be
massaged into readable and understandable text is not going to fly.
And doing that with "it's a lot of work [so could reviewers please do
that work themselves and spare me the efforts]" as rationale...

From: Linus Torvalds <torvalds@osdl.org>
Newsgroups: fa.linux.kernel
Subject: Re: [howto] Kernel hacker's guide to git, updated
Date: Thu, 29 Sep 2005 21:56:36 UTC
Message-ID: <fa.g1q75b7.hg27at@ifi.uio.no>
Original-Message-ID: <Pine.LNX.4.64.0509291451540.5362@g5.osdl.org>

On Thu, 29 Sep 2005, Dave Jones wrote:
>
> What I find amusing is that it was a patch rejection mail from you
> *years* back (circa 2000 iirc), telling me my pine corrupted whitespace,
> that made me switch MUA ;-)
>
> All these years later, and it's still buggered ?

Actually, it seems better. It seems to be buggered by default, but it used
to be that you had to actually recompile pine to make it behave. Now you
can just disable "strip-whitespace-before-send" and _enable_
"quell-flowed-text" and those together seem to do the trick. No extra
patches or recompiles necessary.

So there's progress.

Of course, pico is still pico. Which I find a bit sad: my editor of choise
is still an improved version of uemacs, and pico actually comes from the
same uemacs history, but has different key-bindings for just enough keys
to be slightly confusing.

Still, that shared history means that I find pico a lot more to my taste
than just about any other emailer editor out there. It may have a few
differences, but it has more things in common..

		Linus

From: Linus Torvalds <torvalds@osdl.org>
Newsgroups: fa.linux.kernel
Subject: Re: [PATCH] IA64,sparc: local DoS with corrupted ELFs
Date: Fri, 08 Sep 2006 15:37:20 UTC
Message-ID: <fa.EhxWfkiqXEOFILb7yx/X/qTcfmE@ifi.uio.no>

On Fri, 8 Sep 2006, Kirill Korotaev wrote:
>
> I even checked the email myself and the only difference between "good"
> patches and mine is that mine has "format=flowed" in
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
> It looks like some mailers replace TABs with spaces when format=flowed
> is specified. So are you sure that the problem is in mozilla?

Hey, what do you know? Good call. I can actually just "S"ave the message
to a file, and it is a perfectly fine patch. But when I view it in my mail
reader, your "format=flowed" means that it _shows_ it as being corrupted
(ie word wrapping and missing spaces at the beginning of lines).

Will apply, thanks. It would be better if your mailer didn't lie about the
format though (treating the text as "flowed" definitely isn't right, and
some mail gateways might actually find it meaningful, for all I know).

		Linus

From: Kirill Korotaev <dev@sw.ru>
Newsgroups: fa.linux.kernel
Subject: Re: [PATCH] IA64,sparc: local DoS with corrupted ELFs
Date: Fri, 08 Sep 2006 16:06:42 UTC
Message-ID: <fa.AsSQzHPX66+OEsjYB891BKyzJwU@ifi.uio.no>

Linus Torvalds wrote:
>
> On Fri, 8 Sep 2006, Kirill Korotaev wrote:
>
>>I even checked the email myself and the only difference between "good"
>>patches and mine is that mine has "format=flowed" in
>>Content-Type: text/plain; charset=us-ascii; format=flowed
>>
>>It looks like some mailers replace TABs with spaces when format=flowed
>>is specified. So are you sure that the problem is in mozilla?
>
>
> Hey, what do you know? Good call. I can actually just "S"ave the message
> to a file, and it is a perfectly fine patch. But when I view it in my mail
> reader, your "format=flowed" means that it _shows_ it as being corrupted
> (ie word wrapping and missing spaces at the beginning of lines).

Oh, I finally found how to tune Mozilla and fix it:

One need to edit defaults/pref/mailnews.js file to have:
pref("mailnews.send_plaintext_flowed", false); // RFC 2646=======
pref("mailnews.display.disable_format_flowed_support", true);

This makes Mozilla to send emails w/o "format=flowed".

Thanks a lot for your patience :)

Kirill

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: [patch 8/6] mm: fix cpdfio vs fault race
Date: Wed, 07 Mar 2007 21:34:07 UTC
Message-ID: <fa.vELNcnC+jOa6dQtCvlnAlg4jLpo@ifi.uio.no>

On Wed, 7 Mar 2007, Andrew Morton wrote:
>
> now that's scary - applying this on top of your
> lock-the-page-in-the-fault-handler patches gives:

This is why you should never use plain "patch" with default arguments in
a script (and probably not even from an interactive command line).

I've said this before, and I'll say it again: "'patch' is incredibly
unsafe by default".

Please use

	patch -p1 --fuzz=0

rather than the defaults (adding "-E -u -f" is also often a good idea,
depending on the source of the patches). And that's *especially* true in
scripts.

Yeah, "--fuzz=0" means that patch will reject more patches, but the
patches it rejects tends to be patches it *should* reject, and you should
take a look at manually (and then you can decide to not use --fuzz=0 if
you think patch does the right thing by mistake).

Also, *never* use "-l" or some of the other flags that make patch even
less reliable. It's already guessing enough. Again, "-l" can be useful if
you're going to check the result manually and fix up whatever bad stuff it
does, but if it's needed, I can almost guarantee that it *will* need
fixing up, which is why using those things in automated scripts is not a
good idea.

If you have git installed, "git apply" has saner defaults than "patch"
does (with "git apply" you have to explicitly loosen any rules, and it
doesn't guess by default). "git apply" also checks the whole patch
"atomically" when applying, so that if there are rejects it won't apply
things partially and force you to clean up.

The "git apply" behaviour is particularly useful, because since it by
default doesn't change anything at all on failure, you can start off with
the strict defaults, and then *if* something goes wrong you can try it
with less strict settings without having to undo some partial patch mess.

Of course, you can do the same with GNU patch by starting off with a
dry-run application and seeing that was ok:

	# is it clean
	if patch --dry-run --fuzz=0 -p1 < ...
	then
		# all ok, just patch, no need to ask the user
		patch -p1 < ....
	else
		# this may do bad things, but let's try, and
		# then tell the user to check the end result
		patch <

		.. generate diff, ask user to check it for sanity ! ..
		.. But *require* manual checking! ..
	fi

My original patch applicator script had

	patch -E -u --no-backup-if-mismatch -f -p1 --fuzz=0

(where that "--no-backup-if-mismatch" is just because with an SCM backing
the setup up, there's just no point - but it depends on your setup, of
course). That was because I had (over painful errors) realized that
allowing fuzz is just a guaranteed way to silently get merge errors.

You can get merge errors even with a zero fuzz (if it happens to find
another place to apply the patch - especially true in very structured
files that have lots of identical line snipptes), but it's a lot less
likely.

			Linus

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: [PATCH] timekeeping fix mismerge
Date: Mon, 14 May 2007 19:25:52 UTC
Message-ID: <fa.PJI/vCf+efE6Ha+jvzwsjX7fCS0@ifi.uio.no>

On Mon, 14 May 2007, Thomas Gleixner wrote:
>
> The time keeping code move to kernel/time/timekeeping.c broke the
> clocksource resume logic patch. Fix it up and move the
> clocksource_resume() call to the appropriate place.

Yeah, looks obvious enough. It had just enough context in the *wrong*
place, that the patch would continue to apply if you used the default
(insane) GNU patch semantics, because GNU patch defaults to --fuzz=2, and
is thus ok if it can find even just a single line around the patch that is
valid.

So it looks like Andrew's patch-application scripts happily added the
"clocksource_resume()" to an insane place, because the one-line context
was

>
> +	clocksource_resume();
> +
>  	write_seqlock_irqsave(&xtime_lock, flags);

ie an empty line and a single write_seqlock_irqsave(). And those two lines
could be found elsewhere in the wrong file.

There's a real reason I consider GNU patch defaults to be totally insane.

I personally use much stricter rules, but what happens is that Andrew's
scripts will apply the patch to the wrong place, and then the diff gets
*re-generated*, so by the time I see it, I see a nice diff that applies
with no fuzz at all.

I don't think re-generating the diff is wrong, and in fact I think you
have to do it, but I think Andrew should use "--fuzz=0" or at least
"--fuzz=1" instead of the default 2. Yeah, it obviously causes more patch
application failures, and it can be very irritating if *most* of those
patches would have applied cleanly and correctly with --fuzz=2, but
--fuzz=2 really is very dangerous. It literally just needed two lines to
match in the wrong place (and as mentioned, those two lines can be
trivial, like in the example - totally empty, even!)

		Linus

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: [PATCH 06/18] x86 vDSO: arch/x86/vdso/vdso32
Date: Tue, 27 Nov 2007 01:55:07 UTC
Message-ID: <fa.i93At58fHHLbmrWO1HSsf59adyo@ifi.uio.no>

On Tue, 20 Nov 2007, Roland McGrath wrote:
>
> > git format-patch -p
> >
> > does the trick at least here :)
>
> Ok, I can use that in future.  I hope it still means that in the eventual
> merged state, GIT will be aware of all the renames.

Git doesn't care. You can do renames by hand, or with "git mv", you can do
them as a delete/create pair, you can use "git-apply" with a rename patch,
and you can do them by re-typing in all of the file contents from scratch.

Regardless of how the rename is done, git will represent the data the
exact same way: the state of the tree before and after.

The rename-patches are a lot denser and a lot more readable for humans (ie
you can actually see what *happens*, unlike a traditional stupid unified
diff), and I was hoping that eventually somebody in the GNU patch
community would see how wonderful the extended patch information is, but
when I tried to write a patch to "patch" to do it, I almost dug out my
eyes with spoons from looking at the source code, so I haven't actually
helped it happen.

So you can ask for patches in traditional format (*most* git command lines
will default to that anyway, and only give a copy-patch with -C or -M on
the command line), or people could realize that "git-apply" actually works
even on non-git source code, and just stop using that abomination that is
"patch" with all of it's totally wrong and unsafe defaults (*).

But whatever works. I'm currently skipping the patches since they didn't
seem like 2.6.24 fodder anyway.

			Linus

(*) Let me count the ways: applying patches partially when it fails
half-way through a series. Defaulting to totally randomly guessing the
path-name skip depth when not explicitly given a -pX option. Defaulting to
"--fuzz=2" which is almost guaranteed to apply a patch even when it makes
no sense what-so-ever. Yes, git-apply has stricter rules, but they are
stricter for damn good reasons. For people who want the insane unsafe GNU
patch defaults, they just have to specifically ask for unsafe modes..

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: [PATCH] fix plip 1
Date: Tue, 27 Nov 2007 03:33:36 UTC
Message-ID: <fa.SHrIhOsYPrnqu2RHqCpyecn/Zf0@ifi.uio.no>

On Thu, 22 Nov 2007, Mikulas Patocka wrote:
>
> netif_rx is meant to be called from interrupts because it doesn't wake up
> ksoftirqd. For calling from outside interrupts, netif_rx_ni exists.

Argh. Can you _please_ use more useful subject lines than "fix plip 1/2"?

Those subject lines are what becomes the single-line description of the
problem, used by visualizers like gitk and gitweb. So "fix plip 1" is a
singularly bad such line!

Which is why it should be something like

	Subject: [PATCH 1/2] plip: use netif_rx_ni() for packet receive

or similar.. (My scripts will then get rid of the stuff in brackets, so
all that is useful for giving information that is interesting while in
*email*, but not when actually applied as a patch)

		Linus

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: [PATCH] Documentation: Add "how to write a good patch summary"
Date: Thu, 16 Apr 2009 20:56:25 UTC
Message-ID: <fa.YLIcdvevQbffeYqXQA7YqPSwXVU@ifi.uio.no>

On Thu, 16 Apr 2009, Theodore Tso wrote:

> On Thu, Apr 16, 2009 at 10:12:55PM +0200, Ingo Molnar wrote:
> > as a bug triager i can, within 1 minute, sort all the commits by
> > risk:
> >
> > Low risk cleanups:
> >     ...
> > Runtime crash fixes:
> >     ...
> > Robustness enhancements:
> >     ...
> > Low-risk features:
> >     ...
> > High-risk features:
> >     ...
>
> Sure, but if that's the goal, maybe instead we should have some
> keywords that we tag onto one-line summary, i.e.
>
> ext4 <LR,cleanup>:

Hell no.

The fact is, those "low risk cleanups" break things.

People who think that you can assess the risk of a commit before-hand and
then rely on it are clueless morons.

Stop doing this. If we're just talking about some machine-readable pattern
matching, JUST DON'T DO IT. It's going to be wrong. It's going to be wrong
because people don't do it right, but it's going to be wrong because even
when people _do_ mark everything right, they'll still be wrong.

Write English. Don't make some idiotic commit markers that will make
things harder to read AND WILL BE WRONG.

			Linus

From: Theodore Tso <tytso@mit.edu>
Newsgroups: fa.linux.kernel
Subject: Re: Fix quilt merge error in acpi-cpufreq.c
Date: Thu, 16 Apr 2009 11:57:56 UTC
Message-ID: <fa.QClMTadJx0IukKTx4jz67dcdbiE@ifi.uio.no>

On Thu, Apr 16, 2009 at 09:56:51AM +0200, Ingo Molnar wrote:
> * Rusty Russell <rusty@rustcorp.com.au> wrote:
> > Anyway, Impact: had lead me to think harder about my messages than
> > the free-form commit style did.  Perhaps it's too rigid, but it
> > helped.
>
> btw., and i think this is the crux of the matter, Rusty was quite
> sceptic about impact lines in the beginning, and did not like them
> _at all_. We had discussions (months ago) about it with Rusty and he
> had a similar position to other "read only" participants in this
> thread.

Hmm, I guess for me what I consider ideal, and what I consciously try
to do, is to include (at most) 2-3 words that describe the impact in
the patch summary line.  Writing a good patch summary line is _hard_;
in 70-75 characters you need to describe both *why* and *what*; it
needs to be something which is both succinct, but which, several
months later, is enough so that someone scanning the patch summaries
has a fighting chance to pick out the relevant patch amongst a sea of
thousands of other patches.

And at least for me, something mechanical just isn't likely to work.
It reminds me of a story when, over 30 years ago, someone at the MIT
AI Lab wrote a proposal to create "programming for non-programmers";
it proposed creating templates so that people who didn't know how to
do things could use as a starting point, and then have expert systems
that would help fill in the rest.  Shortly after this paper was
circulated, a parody was sent out mocking the first paper, "thinking
for non-thinkers".  It suggested creating template idea for people who
weren't smart enough to create their own original thoughts, etc.

So I'd really like to encourage try challenging people to try to write
a good patch summary line.  It may be that forcing someone to
constrain themselves to 70 characters (75 if they must) and which must
explain both the impact of the patch as well as the what the patch
does, is enough rigidity or a constraint that it might force people to
think.  Because at the end of the day, that's what we really need
people to do.

              					- Ted