I'd write the bugzilla concept that interfaced w/ lkml to automatically
run queries and email results to "loop doesn't compile". It would also
cross check at bug submission time for possible dupe entries and ask the
submitter if he really wanted to continue.
If you make it easy to use and it has the answers you need, it will
create it's own success and by that, it'll draw a lot of these lkml
repeats from the list. the SNR will increase and users will be happier.
Instead of going to google and getting 947 mostly similar pages to the
same sender/replier and 3 pages that you actually could use..you could
visit the kernel bugkeep lair.
What is needed is a well designed interface to a DB, not YAB (yet
another bugtracker) that isn't intuitive and thus won't be used. Most
of the reason why such a DB is looked down on is because we have seen
way too many wonderful new ideas that have a horrible UI. So people
don't like it or the 20 that came before it, so they expect the next new
wonderful idea to also turn out bad. Not to mention that the author
didn't do it exactly like they envisioned it.
>it still requires some dumb^Wpoor sap to go in pruning them,
>plus once it gets to a certain point, there will be dupes.
>Oh boy will there be dupes. People will check for them first you say?
>Some people are _still_ getting "Loop doesn't compile in 2.4.14"
>Why search archives when you can be the 900th person to ask the
>same question. Even Richard Gooch's page for showing whats wrong
>with the current kernel and how to fix it to get it to compile
>seems to be completly overlooked. Maybe if it were moved to
>www.kernel.org people would see it ? *shrug*
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/