Hiro, >With all due respect, this is hard to believe hearing from ex-QA. In the >real world, developer will not take a look at the bug if QA doesn't >present the bug report with the hard fact, not just a guess. To report a >bug, you often have to go back to a clean machine and make sure the bug >is still reproducible, or run a debugger to gather a hard facts, if there >is no reproducible steps.
With all due respects, sounds like you've never run a testing department or, probably, even been in QA for a commercial product. I've worked on projects with literally hundreds of bugs... do you think it is practical to rebuild a computer "fresh" every single time the slightest problem arises? No. You chase down the obvious first, then resort to something like that only when the obvious is ruled out. >In the real world, you can't call it a bug until you have hard evidence >to point finger with. The way it works in the real world is you identify the problem first, then you see if it is reproducible, you document the steps to reproduce, and finally present the report to the development team. And that is what I did. In the real world you do not go chasing down the unlikely leads until there is a substantial reason to do so. Otherwise meaningful testing would come to a standstill rather quickly. >I am not saying PM is bug clean, and I am not saying your problem is not >PM related for sure. But you are saying that far less likely things should be checked out first. Things which which are not even necessarily applicable to, or possible with, my particular system. Why not check the most obvious lead first? >In fact, I have the same problem as you have. I >get frequent indices rebuilt after PM crash, but my problem is clearly >related to PM since crash happens when downloading emails, and it is easy >to understand why indices corrupts during the course of the action. As were the previous problems I had that required 16 hour rebuilds. Instead of suspecting hardware or the System OS and going through many long hours of probable goose chasing (i.e. rebuilding my entire, otherwise stable system) I looked at PM first. That was the logical thing to do. And guess what? PM was the culprit and Jerome's simple work arounds apparently fixed my major problems. That doesn't mean that it is with this other problem, but it validates the approach I took. >Back to your problem, none of us can reproduce your problem, Sounds like none of you (i.e. you, Ben, and kename) are using 10.2.8 so that is not surprising since so far my problems appear to be related to 10.2.x. >that is, >Open PM, >Check no disk I/O activity present, >Cold reboot, >Open PM again, >-- You get PM goes into 16 hours errands, but non of us does. > >The first thing you _have to_ do is to create new user with empty PM >database then try to reproduce the problem *before* you call it a bug. No, the first thing to do is contact tech support to see if there are similar problems. So I contacted this list, found out that some people had similar problems, the programmer asked for log, I provided one, and the programmer told me these problems are known and that there are work arounds (though they were not on the technical FAQ as far as I could see). I am a customer, not CTM Dev's QA department. Big difference between the two. >It well may be your database is already corrupt, and you do know well as >you used to be a QA that database could corrupt easily. If that the >case, you need to rebuilt your database with other tools than PM itself >if it didn't work. You seem to forget that my logic and my methodology got my problems solved with a fraction of the disruption and time than yours would require. Remember, I don't work for CTM Dev. I am an end user. I have better things to do with my time than debug someone else's program. Fortunately Jerome has been very helpful and fixed my problems without asking me to do an unreasonable amount of disruption and potential harm to my own system. And I wouldn't have done that anyway... I would have switched email applications to one that offered me more stability. Again, thanks to Jerome I'm sticking with the application I prefer. Now, off to crash my system and *hopefully* create a corrupt file that will help Jerome figure out why things aren't working the way he says they should be. Steve
