As Mikus found when he was looking at the long page problem earlier, the best thing that you can do to help us is to determine which build a problem started in. In most cases, you can find the code that was checked in that caused the problem.
With the long page problem, we were able to find exactly the checkin that did it: http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=nsViewManager.cpp&root=/cvsroot&subdir=mozilla/view/src&command=DIFF_FRAMESET&rev1=3.202&rev2=3.203 We just don't know why. Note this is a cross-platform change, NOT an OS/2 speciifc change. Just about every day, we upload two builds - these are found in: http://ftp.mozilla.org/pub/mozilla/nightly/2001-XX-YY-08-trunk/ and http://ftp.mozilla.org/pub/mozilla/nightly/2001-XX-YY-16-trunk/ where XX is the month and YY is the day. By determining in which build the problem started, you can determine what code was checked in to cause the problem. For instance, if someone told me the problem happened on the build from 2000-11-06-08, but not in the build from 2000-11-05-16, then I can use a mozilla.org tool called bonsai to find out what things got checked in and so can you. The tool is at http://bonsai.mozilla.org. In this case, I would query bonsai for all changes between November 5th at 4PM and November 6 at 8AM. I would then scan through these changes to see if anything jumped out at me as to what could have caused the problem. Note that the times in bonasi are west coast times and they correspond to the build times. KNOWING WHEN THE PROBLEM STARTED IS THE MOST IMPORTANT INFORMATION IN DEBUGGING A NEW PROBLEM. I think what I am going to do is try to introduce everyone to a new mozilla.org tool every few days. Hopefully we can get some other people learning this stuff. Here's everyone homework to use bonsai: Find out how many changes I have checked in in the past month. My CVS id is mkaply%us.ibm.com Thanks for your support Mike Kaply IBM
