linux-kernel - Re: [GIT PATCH] HID and USB HID update for 2.6.21-rc2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 28 Feb 2007 10:20:08 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jiri Kosina <jkosina@...e.cz>
cc:	linux-kernel@...r.kernel.org
Subject: Re: [GIT PATCH] HID and USB HID update for 2.6.21-rc2

On Wed, 28 Feb 2007, Jiri Kosina wrote:

> On Wed, 28 Feb 2007, Linus Torvalds wrote:
> 
> > There is no excuse for putting a large array in a header file and 
> > including it millions of times. Or even just twice. The point of a 
> > header file is to *declare* things, not to have big data structures in.
> 
> The point was that noone else than hid/hid-core.c would ever be going to 
> include this header with blacklist.

So:
 - clearly other people *do* include it.
 - if no-one else incldues it WHY HAVE IT SEPARATE!
 - if you want to have it separate for other reasons, YOU MAKE IT A .c 
   FILE, SINCE IT'S CLEARLY NOT A HEADERFILE!

In other words, there is *zero* excuse for that braindamage.

> But OK, I will leave it in there.

No. You need to realize just WHY it was wrong. Not just an "But OK".

Because if you don't see why I'm complaining, I can't pull from you. You 
can send me patches, but for me to pull a git patch from you, I need to 
know that you know what you're doing, and I need to be able to trust 
things *without* then having to go and check every individual change by 
hand.

If I have to check changes like this by hand, I want you to send patches 
to the mailing list, so that other people can help me filter it out. It 
really is that simple, and that fundamental. It's about code flow, and 
it's about the fact that there's no way I can look at every change and vet 
it for being sane.

I simply *cannot* do git-to-git merges with people I can't trust to have 
good enough judgement that I don't need to do the micromanagement and 
check everything myself. I can't afford to. I don't have the bandwidth, 
but I also simply don't have the interest in micro-managing.

So people I do git merges with need to show that they have good taste and 
skills, otherwise it needs to be done as open patches where *other* people 
with good taste and skills can help me.

		Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/