it's your judgement call i guess - i just wanted to challenge the
terminology of calling it a fix ;-)
Can you think of any good way of reintroducing the good aspect of the
WARN(), without the false positives? [ If not, and if the WARN()s do
more harm than good then it's the right change. ]
But generally the trend is the opposite direction: we try to add as many
WARN()s as possible, and we need even more good WARN()s in the kernel.
When we meet false positives we try to improve the quality/yield of the
warning, not eliminate it.
Granted, they are a bit embarrassing when they show up in the top 10 but
they are also very helpful and are tracked very nicely and lead to
actual bugfixes that _matter_.
Kerneloops.org is a wonderful tool: it enables a broad spectrum of users
to help us out with their feedback, without them being forced into any
manual work, and without them having to understand the kernel bug
reporting workflow. Its scale is already enormous: 3000+ bugs reported
per week. (many kudos Arjan!)
Once its growth stabilizes (all the large distros have it either enabled
today or have the client in their pipeline) we can even observe
long-term trends and estimate release-to-release suckiness. That was
impossible before and maintainers were left largely to imprecise
intuitive guesses about where we stand wrt. kernel quality.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
