On Mon, 30 Apr 2007, Indan Zupancic wrote: > I don't know, but what about telling the hapless person who went > through the process of posting a bug what's wrong with the bug report?
It's a tedious process you keep doing over and over and over and over again, and my experience shows it's sheer luck if people can actually fill in the missing bits given the list. Usually you have to ask thrice to obtain even the most essential information such as version. Let alone vendor patches. Anyways, the solution to this problem is someone _politely_ asking reporters to provide necessary information and also point out that they cannot ever hope to have their bug fixed without making a best-effort attempt at answering all questions the first time they're being asked. There are notable exceptions, people pinpointing code fragments at fault and everything, but those are usually tech people and not end users. > That said, if someone is an obvious idiot, ignoring saves time. But I > think that's quite rare, and in general you should give the reporter > feedback, and then ignore the bug report. (Until it improves.) And that is what happens all too often (not in absolute figures, but in the developer's perception of it) - insufficient information to debug. Yes I know, some of the bugs hide themselves so well you actually need four or five reports by different people to actually pinpoint the bug, perhaps accompanied by insufficient interface documentation that make it difficult to verify assumptions/expectations or assess potential solutions (such as the res_init() issue in fetchmail, or probably the khubd going south issue in Linux), but that's not the point. -- Matthias Andree - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/