On Wed, 16 Jul 2008, pageexec@freemail.hu wrote:Oh, so now you're suddenly fine with not doing "full disclosure"? Just a few emails ago you berated me for not doing full disclosure, but now you're saying it is fine? Can you now admit that it's a gray line, and that we just have very different opinions of where the line is drawn? I literally draw the line at anything that is simply greppable for. If it's not a very public security issue already, I don't want a simple "git log + grep" to help find it. That said, I don't _plan_ messages or obfuscate them, so "overflow" might well be part of the message just because it simply describes the fix. So I'm not claiming that the messages can never help somebody pinpoint interesting commits to look at, I'm just also not at all interested in doing so reliably. And I believe you now at least understand the difference. I draw the line between 0 and 1, where 0 is "explain the fix" - which is something that any - and every - commit message should do. Linus --
| david | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Bart Van Assche | Integration of SCST in the mainstream Linux kernel |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Heiko Carstens | Re: -mm merge plans for 2.6.23 -- sys_fallocate |
git: | |
| David Miller | Re: [GIT]: Networking |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 05/37] dccp: Cleanup routines for feature negotiation |
| Lennert Buytenhek | [PATCH 16/39] mv643xx_eth: get rid of ETH_/ethernet_/eth_ prefixes |
