Larry,

>>I'm NOT saying that MS should come up with dialogue between submitters and debuggers (though that would be most sensible) when MS can't reproduce a reported bug. I am saying that MS needs to find a way to INFORM a submitter of one fo the two possible outcomes: reproduced and logged, *or* DROPPED. That way a submitter could at least submit another, with more information.
>>
>>Surely the wizards of MS can come up with a nice clean simple way to achieve this without unduly burdening their people with 'excessive' paper work!
>>
>
>Jim,
>I'm going to disagree with you.
>
>1. I don't think a bug EVER gets dropped. With systems I deploy, I keep track of all bugs reported. The reports with reproducible steps get higher priority than the ones where I have to guess and/or go back to the user. When I get to a point where the reproducible bugs are corrected and I have time, I go back and try to work through the others. I think many developers work this way.

You don't drop them but I interpret that MS does (or effectively ignores them anyway). I
>
>2. MS has posted (and I agree with it) that bug reports should contain steps or code to reproduce the "buggy" behavior. The onus is put on the developer to do this. If they don't/won't, I don't think they have have much say in the matter. If someone took the time to 1) figure out what they did and 2) write it down, it makes it easier all the way around. If a user simply fires off a bug report saying "This is broke, fix it", that gets put in the LOW priority bucket.

That's obvious, Larry. It is the case where a reporting party HAS supplied all of the code and other information that s/he KNOWS causes the problem on their system yet it doesn't reproduce when MS tries it that is a problem.
How can that be?. . . all kinds of reasons, as we have seen here many many times. Sometimes it has to do with other seemingly unrelated software running on the reporter's system. Sometimes it has to do with the maintenance level of the seemingly unrelated software on the reporter's system. Sometimes it has to do with the presence of field names bigger than 10 characters, or the presence of a memo fields, or the setting for buffers, or... or... or... There are simply so many other related aspects that there is a strong possibility that the reporter simply doesn't know that those other aspects are, in fact, implicated.
So the poor guy submits it (remember, with ALL details sensible AND code that reproduces it on his system), MS tries it, and they don't get a failure.
Whether they toss it or not, the poor guy who submitted it is confident that MS is hard at work on his problem because he can make it happen at will on his system. Meanwhile, of course, MS cannot work it.

WHY cannot MS devise a way to let submitters of problems check on the reproducibility status of the specific problem that they have submitted????

Frankly, it seems only common courtesy.

>
>Whil Hentzen spoke a few years ago to a group within the company I was working for. His stance was a bug was not a bug if it couldn't be reproduced. If you can make it bomb, just tell MS how you did it. You know the most about what you did to make it not work.

And how would I know that it was the mouse driver on my system that made MY VFP malfunction??? How would I know that it was an uopdate of MDAC several months ago that is impacting MY VFP now??? How would I know that it is only when I have used BUFFEROVERRIDE and SET DELETED is OFF and have a table that is USE AGAINed that I get a problem with a record not saving>???
These bugs *COULD* be reproduced IF MS duplicated my system to a tee. Since they cannot, then at least tell me that you could NOT reproduce it.

Jim