On Tue, 3 Nov 2009, Luis R. Rodriguez wrote: > > How this sort of issue is dealt with is subjective and it is up to > maintainers to deal with. Not when they then complain when others hit the same issue several days later. > Having more information on the patch and better communication about > the issue it solved, and the issues that reverting it would have > caused would certainly have helped maintainers make a better call at a > regression caused by it but knowing Johannes he'd probably cook up a > followup fix ASAP and that is exactly what he did. He may have cooked it up, but he didn't send it to me, and he didn't even bother to post it as a response to people who complained about the same commit. The fact that people on the wireless mailing lists may have known about this just makes things _worse_, I think. It shows that we really _need_ to go around maintainers, when not going around them seems to result in days of delays and total waste of time for everybody. Btw, the reason it's likely not getting a lot of reports is not because people aren't hitting it, but that the symptom when you _do_ hit it tends to be a dead machine. If you were running X, you have no idea what happened. This is why "I have one NULL pointer dereference report" should mean "The fix needs to go upstream _now_". (And no, as far as I can tell, it needs no suspend/resume cycle at all. I don't know the code very well, but as far as I can tell it just needs a wireless deauthentication, which easily happens if you're running something like NetworkManager and your wireless network may be noisy or weak). Linus -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
