On Sat, 12 Apr 2008, Tilman Schmidt wrote:...No, useless bug reports don't lead to a solution, ie., that particular bug won't get fixed as a result of the report! That's what these people are trying to say. Sure the point of bug reports is to get the bugs fixed, don't you think? :-/ ...Or do you thing it's only secondary to get them fixed. I'm asking the same thing from you as I did from Mark (it still remains unanswered)... What's your suggestion, how should we have solved this particular case? Do you join those that ask for developers to "invest" time to repeatedly go through the commits that are not guilty? ...One would never find the solution by that method :-/. Yes, I'm fine that you don't want to help (or would want but cannot help like have been with many of nearly impossible to reproduce bugs with TCP lately) but the sole consequence is that the bug remains unsolved, it's plain simple. That's until somebody else is affected and reports and we get the necessary information. Or alternatively somebody just reads the offending code (possibly much later) and begins to wonder why there's this particular thing missing there (this is in fact not related to the bug reports at all, many bugs are found this way but it's not a thing one can force to happen in a timely manner :-)). Please reread the thread, this couldn't be farther from the truth... ...Dave had suggested Mark would have to bisect, I suppose this was after founding out that there wasn't anything particular that should cause this kind of behavior, or at least he couldn't find anything even suspicious looking. Mark, with rather demanding tone, was _also_ asking for that "somebody" who did all those TCP fin/closing changes (that would be me) to be responsible over them, ie., those parts that Dave had checked and found not suspicious (and bisect also proved them innocent later on). Yes, I then went through that "mountain of commits" which Mark "was not willing to do" himself. I invested the time even after Dave had also come to the same conclusion as I again did, that there is nothing wrong with the particular parts of the TCP. Funny, since it seems that even Mark himself had come to that same conclusion as both Dave and myself then came (though I cannot really speak for him). So I was third one to check those parts which were then found not guilty, would I be angry about it, I would call that plain waste of time :-). Please note too that I would have gone through them without his remarks as well to just check the thing I already knew. So what's the problem with that. The thing that Mark wasn't very willing to go through that "mountain of commits" and made some accusions that one shouldn't ask user to do that, yet he was doing the same thing, asking for me to go through that "mountain of commits". I don't find that as polite as you do (and maybe you don't honestly either), especially as that was _already done by Dave_, yet it wasn't enough for him. [...doctor part snipped...] But you would feel qualified to tell how the police/doctor must handle it? ...That was the main problem. To conclude I moved this your case down here... It's perfectly fine that you report bugs, even with little time :-). But then if you are asked to do something that is necessary to help developers and you are not willing to do that, please don't start adding demands (it might actually be quite hard to restrain oneself from adding hidden "attacks" to wording, at least for me). Also we have to then accept the concequences, ie., the bug won't get fixed because of that report (unless something comes up later which connects the pieces). I thought the same earlier, but I want to try to correct the misunderstand you are tryng really hard to get here :-). -- i. --
| Ingo Molnar | [patch 12/13] syslets: x86: optimized copy_uatom() |
| Greg Kroah-Hartman | [PATCH 017/196] aoechr: Convert from class_device to device |
| Yinghai Lu | Re: 2.6.26, PAT and AMD family 6 |
| Jan Engelhardt | intel iommu (Re: -mm merge plans for 2.6.23) |
git: | |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | [GIT]: Networking |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Natalie Protasevich | [BUG] New Kernel Bugs |
